尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

web缓存投毒和欺骗前置基础-网络缓存投毒

web缓存投毒和欺骗前置基础-网络缓存投毒 网页缓存有什么用网页缓存的核心价值在于提升效率和体验主要体现在以下几个方面提升加载速度这是最直观的好处。从本地硬盘或就近的服务器读取数据远比从遥远的源服务器通过网络下载要快得多能显著减少网页的加载时间。降低服务器负载缓存减少了直接发往源服务器的请求数量。对于访问量大的网站这能有效避免服务器因过载而崩溃。节省网络带宽由于重复的资源不需要反复从服务器下载可以大大减少网络数据传输量无论是对网站运营方还是使用移动网络的用户来说都能节省成本。怎么察觉到或观察到网页缓存你可以通过以下几种方式来感知和观察网页缓存的存在亲身感知最直接的体验就是第一次打开某个网站时速度较慢但刷新页面后速度会明显变快。这是因为首次访问时所有资源都需要从服务器下载而刷新时很多静态资源如Logo、样式表已经缓存在你的电脑上了。使用开发者工具这是观察缓存最有效的方法。以Chrome浏览器为例在网页上按F12打开“开发者工具”。切换到Network网络标签页。刷新页面你会看到所有资源加载的请求列表。观察Size大小这一列如果显示为(from disk cache)或(from memory cache)就说明这个资源是从你的本地缓存中加载的没有产生网络请求。查看浏览器缓存内容你可以直接看到浏览器里存了哪些东西在开发者工具中切换到Application应用标签页。在左侧的Storage存储菜单下你可以看到Cache Storage、Cookies等这里面就存放着网站的各种缓存数据。为什么会有网络缓存网络缓存的存在是为了解决互联网访问中的几个核心痛点解决网络延迟数据在网络中传输需要时间尤其是当服务器和用户距离很远时。缓存通过将内容放置在离用户更近的地方如本地浏览器或CDN节点极大地缩短了数据传输的物理距离和时间。应对高并发访问想象一下如果一个热门新闻网站的所有访问请求都直接打到同一台服务器上服务器很可能会不堪重负。缓存可以将这些请求分散到各个缓存节点有效分担了源服务器的压力。提升整体网络效率通过减少对相同内容的重复传输缓存节省了宝贵的网络带宽资源让整个互联网的运转更加高效和经济。那么怎么查看本机保存的缓存呢注意保存的地方由于浏览器不同保存的地址也存在不同所以cmd命令不通用那么首先理解网络缓存投毒是什么东西攻击者 → 欺骗并污染 CDN 节点的缓存 → 影响所有访问该节点的正常用户 → 恶意内容在用户的浏览器中加载和执行缓存投毒的核心目标就是污染位于你和网站源服务器之间的那些共享缓存服务器而内容分发网络CDN就是其中最常见、影响最广的一种cdn不是节点吗和缓存投毒有什么关系cdn是节点-为了提高响应速度在一定区域内的用户发起的请求都会发送到这个cdn中由cdn处理对cdn缓存投毒实际上就是让在一定范围内的用户cdn范围内的用户请求到的缓存被替换为攻击者的恶意缓存从而在每个用户电脑加载那么缓存投毒的前置条件是什么怎么让cdn存储有毒的缓存怎么骗黑客的目的不是本地缓存而是cdn节点中的缓存利用 CDN “只看文件名URL存档不看文件内容” 的懒惰习惯夹带私货恶意头让源服务器生产出毒文件最后让 CDN 误以为这是正经文件而存了起来。第一步利用“认知偏差”构造请求黑客需要构造一个“两面派”的 HTTP 请求。这个请求在 CDN 看来是正常的但在源服务器看来是特殊的。对 CDN 说明面上的 URL黑客请求的是GET /index.html。CDN 的心理活动“哦用户要首页。我看下缓存……哎呀没缓存或者过期了那我去源服务器帮用户取一下。取回来我就存为/index.html。”对源服务器说藏在背后的 HTTP 头黑客在请求里偷偷加了一个特殊的头比如Host: evil.com或者X-Forwarded-Host: evil.com。源服务器的心理活动“收到请求。咦请求头里说主机名是evil.com那我得按配置生成一个指向evil.com的登录页面给他。”第二步利用“缓存键”的缺陷这是“骗”的核心。缓存键是 CDN 用来给文件起名字、做分类的唯一标准。CDN 的默认规则大多数 CDN 默认只把URL 路径比如/index.html当作缓存键。它默认忽略HTTP 请求头比如Host或X-Forwarded-Host。黑客的算盘“只要我请求的 URL 是/index.html不管你源服务器返回的是什么内容哪怕是返回了一张图片或者一段恶意代码CDN 都会把它当作/index.html的正常内容存起来”第三步诱导源服务器生成“毒内容”黑客发送出这个精心构造的请求后数据流如下黑客 - CDN发送GET /index.html(带恶意头Host: evil.com)。CDN - 源服务器CDN 忽略恶意头或者没意识到它的危害把请求透传给源服务器。源服务器 - CDN源服务器是个老实人它看到了恶意头生成了一个包含恶意链接的 HTML 页面毒内容返回给 CDN。CDN 的处理被骗成功CDN 收到响应。CDN 问“这个响应对应哪个缓存键”规则说“对应/index.html。”CDN 动作把这份毒内容以/index.html的名字存进了缓存库。总结下1. 目标存在前置条件这是攻击能够成立的基础。如果目标不满足这些条件后续的探测和利用都无从谈起。存在CDN/缓存层目标网站必须使用了CDN或反向代理等缓存技术。加载缓存网站的某些资源如HTML页面、JS文件等被配置为可缓存通常响应头中会包含Cache-Control: public等字段。2. 源服务器和CDN节点处理请求有差异这是漏洞产生的核心根源也就是我们之前反复讨论的“认知偏差”。CDN的认知它根据一套规则通常是URL来定义“同一个请求”并以此作为缓存键Cache Key。源服务器的认知它处理请求时会考虑更多的信息比如HTTP请求头X-Forwarded-Host、Cookie或查询参数并根据这些信息动态生成响应内容。差异点当源服务器用来生成内容的某个参数没有被CDN包含在缓存键中时这个“认知差异”就产生了可利用的漏洞。3. 探测出确实有问题这是将理论转化为实践的关键步骤目的是找到那个具体的“认知差异”点。目标找出那个“能改变源服务器响应内容但又被CDN忽略”的参数即“未键控输入”。方法通过自动化工具如Param Miner或手动方式向请求中添加不同的HTTP头或参数观察响应内容是否发生变化同时确认CDN的缓存状态。4. 进行利用缓存投毒这是最后一步将探测到的漏洞付诸实践完成攻击。构造恶意请求利用上一步发现的“未键控输入”构造一个能诱导源服务器生成恶意内容如XSS payload、钓鱼链接的请求。污染缓存发送这个恶意请求让CDN将这个恶意响应以正常资源的身份存储起来。攻击生效此后所有请求该资源的正常用户都会从CDN直接获取到这份被污染的恶意内容。第一步人工试探寻找突破口怎么做在 Burp Suite 的 Repeater 中手动在请求头如X-Forwarded-Host: test123、URL 路径或参数中注入无害的标记字符串。目的快速验证目标是否存在“未键化反射”。 进阶技巧除了普通的字符串你还可以尝试注入路径混淆如/images/../index.html或双重 Host 头看看目标是否会因为解析差异而“吐”出特殊内容34。第二步工具确认扩大战果怎么做人工发现某个头比如X-Forwarded-Host有反射后立刻把这个线索交给Param Miner等工具。目的人工只能测几个头而工具可以帮你自动测试字典里的几千个 Header找出目标所有存在反射的“未键化输入”3。⚠️ 核心提醒工具报出“Unkeyed Input”时千万不要直接当成最终漏洞。因为有些参数虽然没在缓存键里但缓存系统可能通过其他机制如 Vary 头进行了隔离。第三步使用 PoC 验证一锤定音怎么做针对工具确认的突破口构造带有恶意载荷如evil.com或scriptalert(1)/script的 PoC 请求发送。目的确认漏洞的真实危害。终极验证必不可少发送完 PoC 后必须打开一个全新的无痕浏览器不带任何恶意参数去访问该页面。只有当无辜的正常用户也能看到evil.com或alert(1)时你的 PoC 才算真正成功然后这个一般是结合xss进行利用返回给其他用户恶意的xss从而实现目标1. 强制回源Cache Busting这是所有测试的绝对前提。方法?cb随机数、?_时间戳、修改Accept-Encoding等。目的确保你看到的响应是服务器实时生成的而不是 CDN 返回的旧缓存。没有这一步后续所有测试都是无效的。2. 识别“未键控输入”缓存服务器决定“是否命中缓存”的依据叫缓存键。任何不在缓存键中、但会被后端处理的输入都是潜在的投毒点。通用的探测顺序如下优先级探测目标常用 Payload说明⭐⭐⭐Host 覆盖头X-Forwarded-HostX-HostX-Forwarded-ServerX-Original-URL最常见用于动态生成绝对 URLJS/CSS/重定向⭐⭐响应头注入X-Forwarded-SchemeX-Forwarded-Port影响协议/端口拼接可能导致混合内容或重定向投毒⭐参数污染任意 GET 参数某些框架会把未知参数拼进页面如错误页、搜索框⭐User-Agent / Referer自定义值少数网站用 UA/Referer 做 A/B 测试或个性化内容关键原则每次只改一个变量观察响应是否有变化。如果同时改多个你就无法确定是哪个起了作用。3. 验证反射与影响找到某个 Header/参数能改变响应后需要确认两件事反射位置它被拼进了哪里script src...→ 高危存储型 XSSlink href...→ 高危CSS 劫持Location: ...→ ⚠️ 中危开放重定向投毒纯文本内容 → ⚠️ 低危需结合其他漏洞缓存性验证去掉?cb后发送相同请求检查响应头X-Cache: hit/Age: 0→ ✅ 可被缓存投毒成立X-Cache: miss/Cache-Control: no-store→ ❌ 不可缓存此路不通 一句话总结通用手法加破坏器 → 逐个试 Header → 搜响应找反射 → 去破坏器验缓存那么对于这个官方实验室为了更明显的看出来加入了百度的网址很明显回显了投毒请求修改清单添加 Cache Buster 参数操作在 GET 请求行的 URL 后追加随机查询参数。示例GET / HTTP/2→GET /?abc1111 HTTP/2目的强制 CDN/缓存服务器回源获取新响应避免命中旧的正常缓存。每次重新投毒时需更换参数值如?xyz999。新增 X-Forwarded-Host 请求头操作在请求头中添加一行值为你的 Exploit Server纯域名。示例X-Forwarded-Host: exploit-0ae00086044f6cc9803eb1bd01e200de.exploit-server.net⚠️ 关键约束仅填域名禁止包含https://协议前缀和/exploit等路径后缀否则会导致目标页面拼接出的 JS URL 无效。移除 Cache-Control: max-age0操作若原始请求中存在Cache-Control: max-age0直接删除该行若原始请求无此头则无需任何操作。目的允许缓存服务器存储本次投毒响应。主动保留或添加该头会明确指示缓存服务器不缓存导致投毒失败。 禁止事项切勿主动添加任何Cache-Control相关头部。1.在漏洞服务器中按照官方的指引构建好2.发送投毒请求对比原始请求来看Cache-Control: max-age0是 HTTP 响应头中的一个指令它的核心含义是该资源在缓存中“立即过期”。具体来说它包含以下几层意思1. 并非“禁止缓存”这是一个常见的误区。max-age0不等于no-store或no-cache。浏览器/中间缓存仍然可以存储这个资源的副本。但是该副本的“新鲜度寿命”为 0 秒意味着它一旦存入缓存立刻就变成了“陈旧stale”状态。2. 每次使用必须重新验证因为资源总是处于陈旧状态所以浏览器在下次请求该资源时不能直接使用本地缓存而是必须向源服务器发起条件请求进行验证浏览器会带上If-None-MatchETag或If-Modified-Since头。如果服务器发现资源没变返回304 Not Modified节省带宽。如果资源已更新返回200 OK 新内容。3. 与相关指令的区别指令含义行为max-age0立即过期但可缓存每次都需验证可能走 304no-cache不信任缓存的新鲜度效果与max-age0基本相同语义更明确no-store完全禁止缓存不存储任何副本每次都完整下载无 3044. 典型使用场景HTML 页面确保用户总能拿到最新的页面结构同时利用 ETag/Last-Modified 机制避免重复传输未变更的内容。API 接口数据频繁变化需要实时性但又希望保留条件请求的优化空间。开发调试阶段防止旧缓存干扰测试。总结一句话max-age0 “你可以存一份副本但用的时候必须先问我一声还新不新鲜。”如果你确实想彻底禁止缓存应该使用Cache-Control: no-store如果只是想让缓存每次都验证max-age0和no-cache都是正确的选择。上面还是直接建议直接bp扫描很明显的能直接看出来这里又漏洞然后在这个中你需要让下个人访问到http缓存投毒的内容需要去除这个立即过期则受害者无法正常访问到所以要去除然后让目标导入你漏洞服务器的缓存3.被触发然后等待10-30秒等待官方机器人访问漏洞即可成功实战怎么发现这个可能被投毒的路径呢1. 核心原理理解什么是“未键控首部”缓存服务器如 Varnish, Cloudflare, Akamai, Fastly在决定“是否命中缓存”时只会根据Cache Key缓存键来判断。通常 Cache Key 只包含URL路径 查询参数。而像X-Forwarded-Host,X-Original-URL,X-Rewrite-URL等头部通常不在 Cache Key 中但后端应用却可能读取它们来动态拼接资源链接。这就是“未键控输入”导致缓存投毒的根本原因。2. 实战发现步骤第一步识别缓存层与缓存状态在测试任何投毒之前必须先确认目标是否存在缓存观察响应头寻找X-Cache: hit/miss,Age,Via,CF-Cache-Status,X-Served-By等。使用工具Burp Suite 的Web Cache Vulnerability Scanner扩展是实战必备它能自动检测缓存行为并标记潜在问题。手动验证对同一请求连续发送两次对比响应时间。第二次显著变快且带有hit标识即存在缓存。第二步探测“未键控首部” (Unkeyed Headers)这是最关键的一步。你需要找出哪些头部会影响响应内容但不影响缓存键。自动化探测使用 Burp 插件Param Miner→ 右键请求 →Guess headers/Guess cookies。它会自动注入数十种非标头部并比对响应差异。手动测试清单重点测试以下头部逐一添加并观察响应体变化X-Forwarded-Host/X-Forwarded-SchemeX-Original-URL/X-Rewrite-URLX-Host/X-Forwarded-ServerOrigin/Referer某些框架会基于此生成绝对URL判断标准如果添加了某个头部后响应体中的URL、重定向地址、JS/CSS引用路径发生了变化但该请求仍然返回X-Cache: hit或缓存未失效则该头部就是未键控的投毒向量。第三步定位可被投毒的“反射点”找到未键控首部后需要确认它是否影响了关键资源的加载搜索响应体在响应中全局搜索你注入的主机名如example.com。关注高价值位置script src...标签中的绝对URLlink relstylesheet href...JSON 配置中的 API 端点Open Graph / meta 标签中的 URLJavaScript 代码内部拼接的路径注意如果反射点只是在 HTML 文本内容中如标题、段落危害较低如果在可执行资源路径中则是高危 XSS/缓存投毒。第四步验证可利用性构造恶意载荷将未键控首部的值替换为你的攻击服务器域名。清除缓存破坏器移除?cbxxx确保请求能命中共享缓存。反复投毒实战中缓存 TTL 未知需持续发送恶意请求直到确认X-Cache: hit且响应体已包含恶意URL。自验证用无痕浏览器访问相同URL确认加载了恶意脚本。3. 实战中的额外技巧技巧说明多语言/地区路径很多站点根据 Header 切换/en/,/zh/等资源路径这类逻辑常依赖未键控头部CDN 特定头部Cloudflare 用CF-Connecting-IP, Akamai 用True-Client-IP不同 CDN 有不同的未键控头部集合Vary 头分析检查Vary响应头它声明了哪些头部参与了缓存键。如果X-Forwarded-Host不在Vary中但影响了输出即为漏洞错误页面投毒有时正常页面不反射但 404/500 错误页会反射未键控头部且错误页也可能被缓存DOM-based 投毒有些 JS 文件本身是安全的但其运行时读取的全局变量由服务端注入受未键控头部控制4. 推荐工具链Burp Suite Professional Param Miner Web Cache Vulnerability Scannernuclei的web-cache-poisoning模板集curl/httpie用于快速手动验证避免浏览器自身缓存干扰
返回列表