理论知识学习

https://portswigger.net/web-security/web-cache-deception

Lab: Exploiting path mapping for web cache deception——实验：利用路径映射进行 Web 缓存欺骗

https://portswigger.net/web-security/web-cache-deception/lab-wcd-exploiting-path-mapping

原理：

路径抽象：
服务器在解析请求时，可能会忽略额外的路径段或将其抽象映射到实际资源，例如 /my-account 和 /my-account/abc 被视为同一资源。

缓存规则利用：
缓存服务器通常会根据 URL 路径和扩展名的组合来决定是否缓存响应。对于一些特定的静态扩展名（如 .css, .js, .png），缓存服务器会默认将这些内容标记为可缓存。

伪造请求：
攻击者构造一个伪造的请求路径，例如 /my-account/abc.js，使服务器返回包含敏感信息的响应（如 API Key）。由于路径包含静态扩展名 .js，缓存服务器会将该响应缓存。

缓存共享：
缓存服务器不区分用户身份，所有用户对相同 URL 路径的请求都会返回缓存的内容。如果受害者访问攻击者构造的 URL，会收到被缓存的攻击者敏感信息，或攻击者会获取受害者的敏感数据。

打靶记录：

输入账户密码后登录的画面，显示username和APIkey

抓包后在url中构造/123.js请求一个不存在的js，页面不显示404，依然显示原界面

第一次发包X-Cache: miss，且缓存时间为30秒

再次发包发现X-Cache: hit

可以得知这个url通过静态后缀名的方式进行规则匹配，缓存被击中

打开exploit server

此处修改为其他的js名称，让缓存新生成，在实战测试中，确保这个路径越随机越好，否则容易造成大型危害，点击deliver发送到受害者

<script>document.location="https://0a10003a03467c1c801b1cad00be009d.web-security-academy.net/my-account/777.js"</script>

新打开一个浏览器，成功拿到carlos的APIkey，这是通过缓存拿到的

总结：

测试存在敏感信息的页面，他对路径的抽象化程度，像上面的案例，就是到达account就截止，后面添加内容依然按照account生成，但是发送给受害者就会导致获取到受害者的缓存，而缓存文件（这里可以被视为静态内容）属于公开访问的，再次访问相当于hit到生成的缓存，于是受害者的敏感信息被窃取

Lab: Exploiting path delimiters for web cache deception——实验：利用路径分隔符进行 Web 缓存欺骗

Exploiting path delimiters for web cache deception

原理：

路径分隔符的解析差异：

• 服务器端：
  在一些 Web 应用中，服务器可以通过某些路径分隔符（如 ; 或 ?）解析路径或查询参数，例如：
  • /my-account?abc.js 被解析为 /my-account（忽略 ?abc.js）。
  • /my-account;abc.js 也可能被解析为 /my-account。
• 缓存层：
  缓存机制通常直接将完整 URL（包括路径和扩展名）作为缓存键。有时，缓存不会识别某些路径分隔符（如 ;），而是直接将带分隔符的 URL 当作静态资源路径，如 /my-account;abc.js。

伪造路径 + 静态扩展名：
攻击者利用这些解析差异，构造一个伪造路径带静态扩展名（如 .js），欺骗缓存服务器，将服务器响应的敏感数据缓存下来。例如：

• URL /my-account;wcd.js 被缓存层认为是静态资源路径，触发缓存规则。
• 服务器则解析为 /my-account，返回用户的敏感信息（如 API Key）。

缓存不区分用户：
缓存服务器通常不区分请求的用户身份，只要路径和扩展名相同，就会返回缓存的内容。这使得攻击者可以通过诱导受害者访问恶意 URL，将受害者的敏感数据缓存，随后攻击者访问相同 URL 即可读取数据。

打靶记录：

登录后一样显示用户名和APIkey，一样进行对方匹配规则的测试

这个时候我们选择使用123.js去进行测试，发现对方已经将这个规则补充，直接识别为js文件返回404了

尝试了/my-account;aaa.js存在回显，表明匹配规则将;后面的内容进行了排除，依旧解析为/my-account，但是缓存会存留完整的url地址

进入deliver界面，对目标发送如下payload

<script>document.location="https://0af500a204c7b4f581ea483e008800dd.web-security-academy.net/my-account;abc.js"</script>

我们成功获取到了carlos的APIkey

总结：

这个漏洞的核心是路径分隔符解析的不一致性导致缓存层错误缓存了敏感数据。前一个测试用例的缓存匹配规则没有针对js等静态文件进行规范，这个测试用例针对这一现象进行了修复，未匹配到文件会返回404，但是针对;分隔符的规则缺少，导致了url依旧被解析为/my-account，于是可以通过;去构造一个url让缓存去存储，以获取敏感信息

Lab: Exploiting origin server normalization for web cache deception——实验：利用源站规范化进行 Web 缓存欺骗

https://portswigger.net/web-security/web-cache-deception/lab-wcd-exploiting-origin-server-normalization

原理：

路径规范化问题：

• 服务端对路径进行了规范化（如解析 .. 为父目录），并将请求路由到目标资源（如 /my-account）。
• 但缓存系统没有进行相同的规范化处理，而是将路径按字面意义存储。因此，当路径中存在 %2f 或类似字符时，缓存系统会认为这些请求是不同的资源，即便服务端将其视为相同资源。

缓存规则冲突：

• 缓存系统对 /resources 目录的请求有特定规则，例如基于目录前缀进行缓存，而未进一步检查路径的实际含义。
• 利用这一点，攻击者可以通过伪装的路径（如 /resources/..%2fmy-account），将原本敏感的 /my-account 请求结果存入缓存，并误导缓存系统认为它属于静态资源。

攻击流程：

• 通过构造请求绕过缓存的目录规则，将受害者用户的敏感数据（如 API key）存储在公共缓存中。
• 通过诱导受害者访问恶意 URL，使得受害者的敏感数据被缓存后读取。

打靶记录：

登陆后依然是存在APIkey的界面，抓包进行查看

我们可以看到在/resources目录下存在js和svg类型的静态文件，我们可以构造如下的payload进行测试

/resources/..%2f/my-account

让源服务器解析后面带着的..%2f即为../，使其认为返回内容应该是/my-account下的

发包发现成功让构造的url路径返回了/my-account路径下的内容，而且X-Cache显示miss，再次发包

这个缓存被成功hit，说明存在此漏洞，构造如下的payload，进入deliver

<script>document.location="https://0a2100f904a782c482a715c7005a002c.web-security-academy.net/resources/..%2f/my-account"</script>

成功拿到了carlos的APIkey

总结：

缓存服务器会对处于某一路径下的全部静态文件进行缓存，而我们可以通过../的方式去将路径修改为需要被获取的页面，也就是源服务器会直接解析我们构造的路径，而缓存服务器会将整个url进行记录并且存储我们伪造的路径下的内容

Lab: Exploiting cache server normalization for web cache deception——实验：利用缓存服务器规范化进行 Web 缓存欺骗

https://portswigger.net/web-security/web-cache-deception/lab-wcd-exploiting-cache-server-normalization

原理：

路径分隔符差异

• 源服务器将 ?、%23（# 的 URL 编码）、%3f（? 的 URL 编码）等字符解释为路径分隔符。
• 这些分隔符会导致源服务器解析的路径与缓存系统的解析方式不一致，从而绕过缓存的保护机制。

路径规范化差异

• 源服务器可能会对路径中的特殊字符（如 %2f、.. 等）进行解析并规范化，而缓存系统可能直接基于未规范化的路径进行缓存规则的匹配。
• 通过插入编码的路径片段（例如 ..%2f），可以绕过源服务器的路径规则，同时干扰缓存系统的路径匹配规则。

缓存污染攻击

• 攻击者通过精心构造的 URL 请求，将恶意路径（如 /my-account%23%2f%2e%2e%2fresources）注入到缓存中。
• 一旦缓存存储了恶意请求的结果，其他受害者访问相同的缓存资源时，就会泄露敏感信息（如 API 密钥）。

打靶记录：

登陆后经典界面，抓包构造如下payload

/my-account%23%2f%2e%2e%2fresources

看到X-Cache=miss，构造如下payload，进入deliver

<script>document.location="https://0a5000c70404209180db0d2800dd00a2.web-security-academy.net/my-account%23%2f%2e%2e%2fresources"</script>

拿到carlos的APIkey

总结：

缓存服务器会将 URL 中的 %23（# 的 URL 编码）解析为路径的一部分，但不会像浏览器那样将其截断为锚点。当构造路径如 /my-account#%2f%2e%2e%2fresources 时：源服务器会将其解析为 /resources，并返回公共资源。缓存服务器会缓存这个路径下的敏感数据。

Lab: Exploiting exact-match cache rules for web cache deception——实验：利用精确匹配缓存规则进行 Web 缓存欺骗

https://portswigger.net/web-security/web-cache-deception/lab-wcd-exploiting-exact-match-cache-rules

原理：

同上，不知道是不是翻译问题，内容跟标题匹配度不是很高，这个实验只是盗取了token利用csrf进行了收件邮箱修改的过程

打靶记录：

这次我们登录，并未发现任何敏感信息，但是存在一个更新邮箱的功能

可以看到邮箱被更新为了test@test.com，进入bp翻看数据包

看到与my-account下返回的csrf值一致，我们利用wcd去获取受害者的token

构造如下payload，发现X-Cache=miss

/my-account;%2f%2e%2e%2frobots.txt

进入deliver，构造如下payload，这个?a在我看来只是为了触发新的请求，让服务器认为不是txt文件从而导致直接返回404，起到一个混淆的作用

<script>document.location="https://0a9e00c503bb5ca381fcfc6e009d000c.web-security-academy.net/my-account;%2f%2e%2e%2frobots.txt"</script>

获取到受害者administrator的token

进入更新邮箱的数据包选择生成csrf的poc，此处我已经将token替换掉了

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
    <form action="https://0a9e00c503bb5ca381fcfc6e009d000c.web-security-academy.net/my-account/change-email" method="POST">
      <input type="hidden" name="email" value="tes&#64;test&#46;com" />
      <input type="hidden" name="csrf" value="8i4T8vFGHexs7RK78c2xDcmySYa9gNiW" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>

直接在deliver里面提交，记得修改之前绑定的邮箱，邮箱更改才会显示靶场通关，这非常重要

总结：

实验内容与标题不符，在我看来更多的是提供了一种wcd+csrf多漏洞利用的形式