企业官网建设流程全解析

• 文档
• 网络安全
• 教程

本文源自开源项目 Learn-Web-Hacking 中 source/vuln/webcache.rst 的技术笔记，并结合仓库内 HTTP 标准文档、RPO 相对路径覆盖攻击笔记 等相关资料展开。Web Cache 欺骗攻击（Web Cache Deception）是一类利用浏览器与服务器 URL 解析差异 + 代理缓存策略缺陷的组合型漏洞，攻击者诱导受害者访问一个"看似静态资源"的 URL，使包含个人信息的动态页面被缓存服务器公开缓存，从而窃取会话标识、CSRF Token 等敏感数据。读完本文，你将掌握该漏洞的完整成因链路、手动验证方法、触发条件判定与三层防御加固方案，并理解它与 RPO 攻击、HTTP 请求走私等"解析不一致类"漏洞的异同。

一、背景：Web 缓存机制为什么会被"骗"

1.1 Web 缓存的核心动机

网站为了降低服务器响应延迟、减少后端压力，通常会在链路中引入CDN（内容分发网络）、负载均衡器（Load Balancer）或反向代理（Reverse Proxy）来实现 Web 缓存。这些组件把频繁被访问的文件（CSS、JS、图片、txt 等公开静态资源）缓存在靠近用户的节点上，命中缓存时直接返回，不再回源到后端应用服务器。

举例来说，网站http://www.example.com配置了反向代理：

• 包含用户个人信息的页面，如http://www.example.com/home.php，由于每个用户返回的内容各不相同，这类页面通常是动态生成、逐请求变化的，因此默认不会被缓存在缓存服务器中；
• 缓存的主要对象是可公开访问的静态文件：css、js、txt、图片等；
• 很多"最佳实践"类文章甚至建议：对可公开访问的静态文件一律缓存，并且忽略 HTTP 缓存头（如Cache-Control、Expires）。

正是这最后一条"忽略缓存头"的建议，为 Web Cache 欺骗攻击埋下了隐患。

1.2 理解缓存相关的 HTTP 头（仓库依据）

要深入理解该漏洞，先要掌握 HTTP 层与缓存相关的关键字段。在仓库 source/network/http/http.rst 中，对这些头有完整收录：

请求头中与缓存相关：

响应头中与缓存相关：

关键点：当代理服务器配置为"按文件扩展名缓存并忽略这些头"时，Cache-Control: no-cache、Expires等指令对代理完全不生效——这正是本漏洞第一个前置条件的技术根源。

二、什么是 Web Cache 欺骗攻击

Web Cache 欺骗攻击（Web Cache Deception）最早由 Omer Gil 在 2017 年系统化公开，其核心思想是：

让代理服务器误以为一个动态页面是"可缓存的静态文件"，从而把含敏感信息的响应公开缓存。

它与RPO（Relative Path Overwrite，相对路径覆盖）攻击高度类似——两者都依赖浏览器与服务器对 URL 的解析方式不一致。在仓库 source/vuln/xss/trick/rpo.rst 中同样强调：RPO 攻击"依赖于浏览器和网络服务器的反应，利用服务器的 Web 缓存技术和配置差异"。二者同属"前端/后端解析差异"类攻击，但攻击目标不同：

2.1 攻击现象示例

当访问一个不存在的 URL时，例如：

http://www.example.com/home.php/non-existent.css

浏览器发出 GET 请求后，依赖于服务器使用的技术与配置，服务器返回了页面http://www.example.com/home.php的内容，但 URL 地址仍然是http://www.example.com/home.php/non-existent.css。与此同时，HTTP 响应头的内容也与直接访问http://www.example.com/home.php完全相同——包括 caching header、Content-Type（此处为text/html）。

也就是说：响应的内容与home.php完全一致，但请求的 URL 却以.css结尾。代理服务器看到的是"一个 css 文件"，而后端实际输出的是"一个 HTML 动态页面"。

三、漏洞成因：完整响应流程剖析

原文档给出了攻击发生时的完整响应链路。当代理服务器配置为"缓存静态文件并忽略这类文件的 caching header"时，访问http://www.example.com/home.php/no-existent.css会发生如下过程：

1. 浏览器请求http://www.example.com/home.php/no-existent.css；
2. 服务器返回http://www.example.com/home.php的内容（该页面本身通常不会被缓存，因为它是动态生成的）；
3. 响应经过代理服务器；
4. 代理识别该文件带有 css 后缀，判断其属于"可缓存的静态资源"；
5. 在缓存目录下，代理服务器创建目录home.php，将返回的动态页面内容作为non-existent.css保存下来。

浏览器 ──GET /home.php/non-existent.css──▶ 反向代理/CDN ──▶ 后端服务器 │ 后端返回 /home.php 的动态HTML内容（通常不缓存） │ 代理按 URL 后缀 .css 判定为静态资源 ──▶ 写入缓存 缓存键：/home.php/non-existent.css

从源码结构看，该漏洞的成立本质上需要两个独立的"错误"在同一条响应链上叠加：

• 后端的"错误"：对不存在的路径home.php/non-existent.css采取"前缀匹配 + 容错"策略，返回了home.php的真实内容而不是 404；
• 代理的"错误"：仅凭 URL 扩展名判定缓存类型，完全忽略Cache-Control/Expires等 HTTP 缓存头。

这与仓库中 source/vuln/httpSmuggling.rst 描述的HTTP 请求走私在哲学上同源——都是"链路中不同组件对同一请求的理解不一致"。走私利用的是Content-Length与Transfer-Encoding的解析分歧，而 Web Cache 欺骗利用的是路径/扩展名解析分歧。

四、漏洞利用：从"被缓存"到"被窃取"

4.1 利用思路

攻击者的目标页面通常包含用户个人信息，例如：

• 账户资料页（/myaccount、/profile）；
• 会话管理页（/settings、/notifications）；
• 交易/账单页（/history、/checkout）。

原文档给出的核心利用手法是：攻击者欺骗用户访问一个以静态扩展名结尾、但路径前缀指向敏感动态页面的 URL，例如：

http://www.example.com/home.php/logo.png?www.myhack58.com

该 URL 看似在请求一个图片资源logo.png（查询参数www.myhack58.com起迷惑作用），但当用户携带自己的会话访问它时：

1. 后端返回该用户的home.php页面内容；
2. 代理按.png后缀将其缓存；
3. 含有该用户个人信息的页面从此被公开缓存，任何人都可以通过同一 URL 匿名访问到。

4.2 敏感信息面

原文档明确指出，被缓存的内容如果包含以下任一数据，风险都会被放大为严重的信息泄露：

• Session 标识（会话 Cookie / Session ID）；
• 安全问题的答案（如密保问题的明文存储页面）；
• CSRF Token。

之所以危险，是因为"大多数网站的静态资源默认都是公开可访问的"——缓存的动态页面被当作静态资源对待，绕过了原有的鉴权/访问控制逻辑。攻击者拿到这些数据后，可以直接接管会话（Session Hijacking）或绕过 CSRF 防护。

4.3 攻击链总结

五、漏洞存在的条件

原文档强调，该漏洞要成立至少需要同时满足以下两个条件：

1. Web cache 功能根据扩展名进行保存，并忽略 caching header；
   • 即代理/CDN 配置为"按.css/.js/.png等扩展名判定是否缓存"，且不校验Cache-Control、Expires等响应头；
2. 当访问不存在的页面（如http://www.example.com/home.php/non-existent.css）时，服务器返回home.php的内容；
   • 即后端应用对"路径前缀匹配"做了容错处理（常见于 PHP 框架的路由 fallback、mod_rewrite重写规则、框架对 PATH_INFO 的解析等），而不是返回 404。

可以从源码结构推断：条件 2 在高版本框架中往往默认不成立（框架默认对不存在路由返回 404），因此实际环境中该漏洞的触发点通常位于遗留的旧路由逻辑、自定义路由重写规则或对 PATH_INFO 处理不当的框架上。两个条件缺一不可，只满足其一不会形成可利用的漏洞。

六、漏洞防御：三层加固方案

原文档给出了三点防御措施，按其根本性排序如下：

6.1 按缓存头决定是否缓存（根治）

设置缓存机制，仅缓存 HTTP caching header 允许的文件，即严格遵循Cache-Control、Expires、Pragma等响应头的指令。

这是从根本上杜绝该问题的方法——动态页面会携带Cache-Control: no-cache/private，代理据此直接跳过缓存，无论 URL 后缀是什么。仓库 source/network/http/http.rst 中列出的这些缓存相关头正是实施该策略时需要在应用层正确输出的字段：

Cache-Control: no-store, private

• no-store：禁止缓存；
• private：仅允许私有缓存（浏览器），禁止共享缓存（代理/CDN）。

6.2 按 Content-Type 缓存（缓解）

如果缓存组件提供该选项，设置为根据Content-Type进行缓存，而非根据 URL 扩展名。

动态页面的响应Content-Type是text/html，而静态资源是text/css、image/png等。代理以Content-Type为判定依据后，即使 URL 以.css结尾，只要响应类型是text/html就不会缓存，从而掐断利用链路。

6.3 修复后端路径解析（消除条件 2）

访问http://www.example.com/home.php/non-existent.css这类不存在页面时，不返回home.php的内容，而是返回 404 或者 302。

• 返回404：路径不存在，直接告知客户端与缓存组件"该资源不存在"；
• 返回302：重定向到正确规范路径，避免 URL 与实际内容错位。

这条措施从源头上消除了"URL 与内容不一致"的畸形组合，也是防御 Web Cache 欺骗与 RPO 攻击共同需要的后端修复——仓库中 source/vuln/xss/trick/rpo.rst 记录的 RPO 攻击同样建立在这种路径解析缺陷之上。

6.4 防御措施对照表

七、真实案例：PayPal

原文档收录了 Web Cache 欺骗攻击的经典真实案例——PayPal。

在未修复之前，攻击者通过该攻击可以获取的信息包括：

• 用户姓名；
• 账户金额；
• 信用卡的最后 4 位数；
• 交易数据；
• E-mail 地址等。

受攻击的部分页面包括：

https://www.paypal.com/myaccount/home/attack.css https://www.paypal.com/myaccount/settings/notifications/attack.css https://history.paypal.com/cgi-bin/webscr/attack.css?cmd=_history-details

可以看到，这些 URL 全部采用了"敏感页面路径 +.css静态扩展名"的标准构造：/myaccount/home/attack.css命中账户概览页、/myaccount/settings/notifications/attack.css命中通知设置页、/cgi-bin/webscr/attack.css?cmd=_history-details命中交易历史详情页。PayPal 在修复后，对这类不存在的路径返回 404/302，并对缓存决策进行了收紧。

该案例说明：即便是安全投入极高的金融类站点，只要缓存策略与路径解析存在配置缺陷，同样会沦陷。同时它也印证了原文档的判断——该漏洞通常一次性影响大量真实用户，因为缓存是全局共享的，一旦命中即被公开。

八、关联知识点与延伸思考

8.1 与 RPO 攻击的异同

仓库 source/vuln/xss/trick/rpo.rst 记录的 RPO（Relative Path Overwrite）攻击与本漏洞的关联如下：

• 相同点：都依赖浏览器与服务器（代理）对 URL 的解析差异，都利用 Web 缓存与配置差异；
• 不同点：RPO 利用的是浏览器对 HTML 中相对路径的解析（结合服务器返回内容）导致加载恶意资源，偏向前端资源劫持；Web Cache 欺骗利用的是代理按扩展名缓存与后端容错路径解析，偏向服务端缓存投毒与敏感数据泄露。

8.2 与 HTTP 请求走私的哲学关联

仓库 source/vuln/httpSmuggling.rst 中记录的 HTTP 请求走私，本质是"前端服务器与后端服务器对同一请求的理解不一致"（Content-LengthvsTransfer-Encoding）。Web Cache 欺骗同样是"链路组件对同一请求的理解不一致"——只不过分歧点从"报文长度"变成了"路径与资源类型"。排查此类漏洞时，应统一梳理链路中每一层的解析规则，保证前后端对 URL 的判定一致。

8.3 与 WAF 部署的关联

仓库 source/misc/waf.rst 提到 WAF 常见的防御方式包括"检测异常协议，拒绝不符合 HTTP 标准的请求"。对于 Web Cache 欺骗而言：

• 基于语法分析的 WAF 可以对"路径以静态扩展名结尾但Content-Type为text/html"的畸形请求进行拦截；
• 但单纯基于关键字/正则的 WAF 很难有效覆盖该漏洞，因为它不依赖恶意 payload，只依赖 URL 形态与缓存配置的组合。

这提示防守方：Web Cache 欺骗是配置缺陷型漏洞，WAF 只能作为补充手段，根除仍需落实第六节的配置加固。

九、验证与自查清单

在实战中验证或自查是否存在 Web Cache 欺骗漏洞，可按如下步骤进行：

1. 识别缓存组件：确认站点是否位于 CDN / 负载均衡器 / 反向代理之后，观察响应头中是否出现Age、X-Cache、Via等缓存相关头（参见 HTTP 标准文档）；
2. 测试后端路径解析：直接请求https://目标/敏感页面路径/xxx.css，观察是否返回敏感页面的内容且状态码为 200；
3. 测试缓存判定：查看该响应的Cache-Control、Content-Type，判断代理是否"忽略缓存头、按扩展名缓存"；
4. 二次匿名访问验证：使用无 Cookie 的全新会话再次请求同一 URL，若能直接获取到敏感页面内容，则证明缓存已生效、漏洞成立；
5. 评估影响面：检查被缓存内容是否包含 Session、CSRF Token、PII（个人身份信息）等敏感数据，评估危害等级。

十、总结

Web Cache 欺骗攻击是一类典型的**"缓存策略 × 路径解析"配置组合漏洞**，其技术核心可归纳为一条链路：

动态响应（敏感）→ 经代理 → 被按扩展名误判为静态资源 → 公开缓存 → 匿名窃取。

它之所以隐蔽，是因为攻击载荷不包含任何恶意字符，仅凭一个畸形 URL 即可完成"投毒"，且受害面覆盖所有曾访问过该 URL 的登录用户。防御的根本在于尊重 HTTP 缓存头、按Content-Type判定缓存、并修复后端对不存在路径的容错返回——这三条分别对应了原文档给出的三点防御措施，也同样是 Web 缓存类攻击（Web Cache Deception、Web Cache Poisoning）通用的加固基线。

本文依据的仓库文档与资料：

• 核心文档：source/vuln/webcache.rst（Web Cache 欺骗攻击全笔记）
• HTTP 缓存相关头字段：source/network/http/http.rst
• RPO 相对路径覆盖攻击：source/vuln/xss/trick/rpo.rst
• HTTP 请求走私（解析不一致类攻击参照）：source/vuln/httpSmuggling.rst
• WAF 防护方式（语法分析类检测参照）：source/misc/waf.rst

• 文档
• 网络安全
• 教程