最近在PortSwigger上做网络空间安全的实验，有很多实验一开始看了前面的理论指导后都还是会有完全摸不着头脑的感觉，找了网上也没有看到能具体把这个实验讲明白的教程。撞墙了很多次终于摸索出来了这个实验，浅浅记录一下和大家分享经验。说的有问题的地方也欢迎大家指正～

实验背景与目的

Web 缓存欺骗（Web Cache Deception, WCD） 是一种利用中间缓存层（如 CDN、反向代理）与后端服务器之间解析差异的攻击方式。
1.攻击背景：为了减轻服务器压力，CDN 往往会缓存 .js、.css 等静态资源。
2.实验目的：

• 构造一个特殊的 URL，诱导缓存服务器将包含用户敏感隐私（API Key）的动态页面误认为静态资源并进行缓存，从而实现非授权访问。
• 掌握burp suite工具通过http
  history找浏览器发送的请求（比浏览器开发者工具更直观，还可用filter过滤），并将请求发送到repeater工具，掌握如何重复发送请求测试被攻击服务器响应。

实验环境搭建

1.点击“access the lab”进入实验室。
2.按照提示登录自己的portswigger信息，注意进入实验室的第一个要求登录页面是要输入自己的账户信息，所以最好先在自己的chrome浏览器完成操作。
3.登录成功后进入实验室主页面。本次实验分为两个页面，一个是博客首页、还可跳转至登录页，一个是攻击者控制的服务器页，在此存放恶意js脚本并推送给管理员，预设管理员会点开该页面。
4.在burp suite的proxy页面，点击open browser，打开burp自带的chromium浏览器，无需配置系统代理，自带证书，能有效避免因普通浏览器缓存导致的实验干扰。
5.注意网络环境：确保本地代理工具（如 Clash）不会干扰 Burp 的 8080 端口监听。

核心操作步骤

1. 寻找漏洞点
   （1）登录账号（wiener/peter），访问个人中心。在 Burp 的 HTTP history 中找到 GET /my-account。
   （2）右键发送到 Repeater。
2. 验证缓存策略
   在 Repeater 中将请求路径改为 /my-account/test.js
   - 第一次发送：返回 HTML 内容，X-Cache: miss。说明后端忽略了后缀，正常返回了隐私页面。
   - 第二次发送：如果在 30 秒内再次点击，看到 X-Cache: hit。
   - 此时，缓存服务器已被欺骗，它把用户的个人资料存成了公共 JS 文件。
3. 构造exploit脚本
   打开 Exploit Server，在 Body 中编写跳转脚本，诱导管理员去触发这个错误的缓存路径：

//注意，你的实验id为博客首页路径上类似“0a32..."等一条字符串，而不是攻击者服务器的路径“exploit-98...."
//不要输错路径，否则管理员点击链接就无法跳转到对应页面，会返回“invalid host”
<script>
    location = 'https://[你的实验ID].web-security-academy.net/my-account/exploit.js';
</script>

点击 Store 保存，然后点击 Deliver exploit to victim。

• 收割API Key
  管理员点击后，他的隐私页面会被缓存在 /my-account/exploit.js。
  立即在浏览器访问该链接，你看到的将不再是自己的页面，而是管理员的页面！直接复制页面上的 API Key 提交即可通关。
  示例：
  如下为初次登录时页面，服务器会给用户分配一个api key
  
  如下为管理员点击链接后，再次访问该链接，我们就可以得到缓存中的管理员api key
  

缓存攻击原理

/account/test.js这里的test其实可以随意命名，包括发送给管理员的恶意脚本中的exploit.js也是如此，重要的并不是具体文件路径，而是.js文件后缀本身。
1.命名可以随便，但后缀不能随便
虽然名字随便起，但我们必须使用一个会被缓存服务器（CDN）认为是“静态资源”的后缀。

• 有效后缀：.js, .css, .jpg, .png, .gif, .txt。这些文件通常不包含用户私密信息，CDN
  为了加速访问，默认会把它们存起来。
• 无效后缀：如果你命名为 test.php 或 test.jsp，CDN 通常会认为这是动态脚本，不会进行缓存，攻击就失效了。

2.核心原理：解释歧义
这个漏洞之所以存在，是因为**缓存服务器（中间人）和后端服务器（源站）**对同一个 URL 的理解出现了“代沟”：
（1）后端服务器（宽容解析）
当我们请求 /my-account/test.js 时：

• 后端服务器（通常是基于某种框架的 Web 应用）会从左往右解析。
• 它发现 /my-account 是一个存在的有效路由，而后面的 /test.js 它根本不认识。
• 为了保证用户体验，它会忽略掉末尾不认识的部分，直接返回 /my-account 的内容。

（2）缓存服务器（后缀优先）
当响应数据经过缓存服务器返回时：
缓存服务器只看 URL 的末尾。
它看到以 .js 结尾，会认为这是一个 JavaScript 脚本文件，它是静态的，可以把它存到我的公共硬盘里，下次用户再要这个文件，缓存服务器就直接给，不再请求后端服务器。

（3）当两个行为叠加到一起，管理员点进攻击链接后，从后端请求的api key就被缓存服务器错误的作为静态资源保存在了缓存服务器中，我们再次请求，就可以直接从缓存服务器拿到管理员api key