WEB安全
00-HTTP协议
01-前端基础【HTML】
02-前端基础【CSS】
03-后端基础【PHP速通】
04-后端基础【PHP面向对象】
05-MySQL基础操作
06-前后端联动【代码练习】
07-SQL注入
08-SQL注入 Labs
09-跨站脚本攻击【XSS】
09-XSS Labs
10-CSRF
11-SSRF
12-XML 外部实体注入【XXE】
13-代码执行漏洞
14-命令执行漏洞
15-文件包含漏洞
16-文件上传漏洞
17-反序列化漏洞
18-业务逻辑漏洞
19-未授权访问漏洞集合
20-跨源资源共享【CORS】
21-SSTI模板注入
22-并发漏洞
23-点击劫持【Clickjacking 】
24-请求走私
25-路径遍历
26-访问控制
27-身份验证漏洞
28-WebSocket
29-Web缓存中毒
30-HTTP 主机头攻击
31-信息泄露漏洞
32-原型污染
33-API概述
34-API分类类型
35-API交换格式
36-API身份验证
37-API常见漏洞
38-crAPI靶场
39-JWT
40-DVGA靶场
41-服务器端参数污染
42-API Labs
43-OAuth Labs
44-GraphQL API Labs
45-JWT Labs
46-小程序抓包
47-云存储
48-对象存储OSS
49-存储桶
50-存储桶漏洞
51-STS访问OSS
-
+
29-Web缓存中毒
浏览
1
## 概述 Web 缓存中毒(Web Cache Poisoning)是一种通过操纵缓存服务器存储恶意响应,导致后续用户获取污染内容的攻击技术。 其核心原理是利用缓存机制对请求特征(如 URL、头部字段)的识别缺陷,将伪造的响应注入到缓存系统。 中毒的网络缓存可能成为传播多种不同攻击的毁灭性手段,利用 XSS、JavaScript 注入、开放重定向等漏洞。 ## Web 缓存的工作原理 Web 缓存是 Web 系统中用于临时存储资源(如 HTML 页面、图片、CSS、JavaScript 等)的机制,其核心目标是减少重复请求、降低服务器负载、提升资源访问速度。它通过在 “用户与源服务器之间” 的 中间节点存储资源副本,让后续请求无需重复访问源服务器,直接从缓存获取内容。 如果服务器必须对每个 HTTP 请求分别发送新的响应,这很可能会导致服务器过载,从而导致延迟问题和糟糕的用户体验,尤其是在繁忙时段。缓存主要是为了减少此类问题。为了解决这一问题,便出现了缓存。 缓存位于服务器和用户之间,用于保存(缓存)特定请求的响应,通常保存固定时间。如果另一个用户随后发送了相同的请求,缓存只会直接向用户提供缓存响应的副本,而无需后端进行任何交互。这大大减轻了服务器的负载,因为它减少了需要处理的重复请求数量。  > 缓存键 当缓存收到 HTTP 请求时,它首先必须确定是否存在可直接处理的缓存响应,或者是否需要将请求转发给后端服务器处理。缓存通过比较请求组件的预定义子集(统称为“缓存键”)来识别等效请求。通常,该子集包含请求行和Host标头,未包含在缓存键中的请求组件被称为“未加键”。 如果传入请求的缓存键与前一个请求的键匹配,则缓存会认为它们是等效的。因此,它将提供为原始请求生成的缓存响应的副本,这适用于所有具有匹配缓存键的后续请求,直到缓存响应过期。 ## 攻击原理与步骤 一次成功的Web缓存中毒攻击通常包含四个阶段: 1、识别未键输入:攻击者首先需要找到一个能被缓存服务器转发到后端应用,但不被包含在缓存键中的HTTP输入。 常见的输入点包括: - HTTP请求头,如 X-Forwarded-Host, X-Host, User-Agent, Referer 等。 - URL参数,如 ?utm_source=test。 - Cookie(较少见,因为它们通常默认在缓存键之外)。 2、触发恶意响应:操纵这个“未键输入”,使后端应用程序在其响应中包含该恶意输入。 例如,攻击者设置 X-Forwarded-Host: evil.com,而后端服务器在响应中使用了这个值来生成一个绝对URL:\<script src="https://{X-Forwarded-Host}/payload.js">\</script>。 3、获取缓存:确保这个恶意响应被缓存服务器认为是“可缓存”的。这通常意味着响应需要有一个合适的缓存控制头(如 Cache-Control: public, max-age=3600),并且状态码通常是200。 4、交付给受害者:一旦响应被缓存,任何其他用户只要请求相同的缓存键(例如,相同的URL路径),就会收到这个被注入恶意内容的缓存响应。 其根源在于: - 缓存服务器错误地认为两个请求是等价的(缓存键设计缺陷)。 - Web应用程序不安全地使用了不可信的HTTP输入。 ## 示例 1. 缓存投毒 + XSS 的复合攻击 某电商平台的 CDN 节点未验证X-Forwarded-Host头,攻击者构造请求: ```http GET /product?sku=123 HTTP/1.1 X-Forwarded-Host: attacker.com ``` 服务器响应中包含\<meta property="og:image" content="//attacker.com/malicious.js">,该响应被 CDN 缓存。后续用户访问时,浏览器自动加载恶意脚本,导致会话劫持。 2. 供应链攻击:Sitecore 平台的 RCE 链 攻击者利用 CVE-2025-53693 的 HTML 缓存投毒漏洞,向 Sitecore 实例注入恶意 HTML,结合 CVE-2025-53691 的反序列化漏洞,最终实现未授权代码执行。攻击路径包括: - 通过 ItemService API 枚举缓存密钥 - 向密钥发送包含恶意 JavaScript 的请求 - 触发BinaryFormatter反序列化漏洞执行任意代码。 ## 防护措施 防御需要缓存服务器管理员和Web应用开发者共同负责。 1. 对缓存服务器(如CDN、反向代理)的建议 - 最小化缓存键:只将必要的字段作为缓存键(通常只是方法、路径和必需的查询参数)。但更要最大化缓存键的覆盖范围,确保所有影响响应内容的输入都包含在缓存键中。例如,如果应用使用 User-Agent 来提供不同的内容,那么 User-Agent 就应该被纳入缓存键。 - 禁用缓存:对于包含敏感头或不可信用户输入的响应,通过缓存控制头(如 Cache-Control: private, no-store)明确指示缓存服务器不要缓存。 - 净化输入:一些高级缓存服务器可以在将请求转发给源站之前,对某些头进行验证或过滤。 2. 对Web应用开发者的建议 - 不要信任来自请求的输入:这是Web安全的黄金法则。所有HTTP头(如 Host, X-Forwarded-Host, Referer, User-Agent)都是用户可控的,必须视为不可信数据。绝不要直接用它们来生成响应内容,除非经过严格的验证和过滤。 - 使用相对URL:尽量避免在响应中生成绝对URL。使用相对路径(如 /resources/script.js)可以从根本上杜绝通过 X-Forwarded-Host 等头进行的投毒。 - 配置缓存控制头:仔细为每个响应设置合适的 Cache-Control 头。对于包含动态或用户相关内容的页面,不要设置为 public。
毛林
2026年11月15日 18:27
转发文档
收藏文档
上一篇
下一篇
评论(0)
登录
后可发表评论
还没有评论,来抢沙发~
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
Word文档
PDF文档(打印)
分享
链接
类型
密码
更新密码
还没有评论,来抢沙发~