实验利用路径映射欺骗网页缓存要完成这个实验你需要知道正则表达式端点如何将 URL 路径映射到资源。如何检测和利用缓存服务器和源服务器映射 URL 路径方式的差异。使用以下凭据登录您自己的帐户wiener:peter登录后便可以repeter账户页面根据以下url请求开始测试/my-account ↓ /my-account/abc ↓ /my-account/abc.js先发送正常请求再发送对/my-account/abc的请求之后可以发送对/my-account/abc.js的请求可以发现出现两个非常关键的响应头Cache-Control和X-Cache解释下X-Cache: missmiss表示这次响应没有从缓存中拿而是去后端服务器重新获取的。可以理解成浏览器 │ │ GET /my-account/abc.js ▼ CDN / 缓存服务器 │ │ 没找到缓存 → MISS ▼ 后端服务器 │ │ 返回响应 ▼ CDN缓存服务器 │ │ 把响应缓存起来 ▼ 浏览器所以第一次访问的目的并不是攻击而是建立基准。Cache-Control: max-age30这个响应头表示如果缓存服务器缓存了这个响应那么它可以在30 秒内直接使用这个缓存响应。所以第一次请求 ↓ MISS ↓ 后端生成响应 ↓ 缓存服务器保存响应 ↓ 有效期 30 秒这就给了我们一个实验条件30 秒内再次请求同一个缓存键有可能不再访问后端而直接拿缓存。30 秒内再次发送再次发送GET /my-account/abc.js HTTP/1.1 Host: example.com结果X-Cache: hit这非常关键。hit意味着这次响应直接来自缓存。流程变成浏览器 │ │ GET /my-account/abc.js ▼ 缓存服务器 │ │ 找到之前缓存的结果 │ │ HIT ▼ 直接返回缓存内容后端甚至可能没有参与这次请求。理解为什么/my-account/abc.js会被缓存这里才是这个实验的核心。正常情况下/my-account/明显是一个动态、私密页面。例如GET /my-account/可能返回h1Welcome, Alice/h1 pEmail: aliceexample.com/p这种内容通常不应该被公共缓存。但是你构造了/my-account/abc.js虽然实际上/my-account/abc.js并不一定真的存在。问题在于缓存服务器可能只看 URL 后缀它可能看到/my-account/abc.js ↑ .js然后认为.js是静态资源应该可以缓存。于是缓存服务器按照类似这样的规则如果 URL 以 .js 结尾 ↓ 认为是静态资源 ↓ 允许缓存但是后端服务器怎么看后端服务器可能没有把/my-account/abc.js当成一个真正的 JavaScript 文件。它可能通过路由机制把它解释成/my-account/或者/my-account/xxx也就是说缓存服务器和后端服务器对同一个 URL 的理解不一样这是整个漏洞的关键。可以画成/my-account/abc.js │ ┌──────────┴──────────┐ │ │ ▼ ▼ 缓存服务器 后端服务器 │ │ 看 URL 后缀 看应用路由 │ │ .js文件 /my-account │ │ ▼ ▼ 可以缓存 私人账户页面于是出现了一个危险情况缓存服务器 /my-account/abc.js ↓ 静态 JS 文件 ↓ 可以缓存 后端服务器 /my-account/abc.js ↓ /my-account ↓ 用户私人数据推理链① /my-account/abc.js ↓ ② 第一次请求 ↓ ③ X-Cache: miss ↓ ④ Cache-Control: max-age30 ↓ ⑤ 说明响应可以被缓存 ↓ ⑥ 30秒内再次请求 ↓ ⑦ X-Cache: hit ↓ ⑧ 证明该 URL 已经进入缓存 ↓ ⑨ 为什么 ↓ ⑩ 缓存可能根据 .js 判断它是静态资源 ↓ ⑪ 但后端可能把它当成 /my-account 动态页面 ↓ ⑫ 缓存层和后端对 URL 的解释产生差异 ↓ ⑬ 可能形成 Web Cache Deception完成实验点击go to exploit server 在body中插入我们想要对用户的网络欺骗代码欺取缓存session后登入账户拿到专属apiscriptwindow.locationhttps://0aea003004e6a85b80a50863004900f5.web-security-academy.net/my-account/xzy.js/script点击Deliver exploit to victim算是发送给用户然后访问以下urlhttps://0aea003004e6a85b80a50863004900f5.web-security-academy.net/my-account/xzy.js获得用户的api key 将其复制提交至submit solution 即可攻克工程极短 但是想要完全理解如何一步一步检测出缓存欺骗的可行性需要花些时间与理解我的攻克过程没能完成hit 可以参考以下视频借鉴学习https://www.youtube.com/watch?v9kGF1O9jyaA
实验利用路径映射欺骗网页缓存要完成这个实验你需要知道正则表达式端点如何将 URL 路径映射到资源。如何检测和利用缓存服务器和源服务器映射 URL 路径方式的差异。使用以下凭据登录您自己的帐户wiener:peter登录后便可以repeter账户页面根据以下url请求开始测试/my-account ↓ /my-account/abc ↓ /my-account/abc.js先发送正常请求再发送对/my-account/abc的请求之后可以发送对/my-account/abc.js的请求可以发现出现两个非常关键的响应头Cache-Control和X-Cache解释下X-Cache: missmiss表示这次响应没有从缓存中拿而是去后端服务器重新获取的。可以理解成浏览器 │ │ GET /my-account/abc.js ▼ CDN / 缓存服务器 │ │ 没找到缓存 → MISS ▼ 后端服务器 │ │ 返回响应 ▼ CDN缓存服务器 │ │ 把响应缓存起来 ▼ 浏览器所以第一次访问的目的并不是攻击而是建立基准。Cache-Control: max-age30这个响应头表示如果缓存服务器缓存了这个响应那么它可以在30 秒内直接使用这个缓存响应。所以第一次请求 ↓ MISS ↓ 后端生成响应 ↓ 缓存服务器保存响应 ↓ 有效期 30 秒这就给了我们一个实验条件30 秒内再次请求同一个缓存键有可能不再访问后端而直接拿缓存。30 秒内再次发送再次发送GET /my-account/abc.js HTTP/1.1 Host: example.com结果X-Cache: hit这非常关键。hit意味着这次响应直接来自缓存。流程变成浏览器 │ │ GET /my-account/abc.js ▼ 缓存服务器 │ │ 找到之前缓存的结果 │ │ HIT ▼ 直接返回缓存内容后端甚至可能没有参与这次请求。理解为什么/my-account/abc.js会被缓存这里才是这个实验的核心。正常情况下/my-account/明显是一个动态、私密页面。例如GET /my-account/可能返回h1Welcome, Alice/h1 pEmail: aliceexample.com/p这种内容通常不应该被公共缓存。但是你构造了/my-account/abc.js虽然实际上/my-account/abc.js并不一定真的存在。问题在于缓存服务器可能只看 URL 后缀它可能看到/my-account/abc.js ↑ .js然后认为.js是静态资源应该可以缓存。于是缓存服务器按照类似这样的规则如果 URL 以 .js 结尾 ↓ 认为是静态资源 ↓ 允许缓存但是后端服务器怎么看后端服务器可能没有把/my-account/abc.js当成一个真正的 JavaScript 文件。它可能通过路由机制把它解释成/my-account/或者/my-account/xxx也就是说缓存服务器和后端服务器对同一个 URL 的理解不一样这是整个漏洞的关键。可以画成/my-account/abc.js │ ┌──────────┴──────────┐ │ │ ▼ ▼ 缓存服务器 后端服务器 │ │ 看 URL 后缀 看应用路由 │ │ .js文件 /my-account │ │ ▼ ▼ 可以缓存 私人账户页面于是出现了一个危险情况缓存服务器 /my-account/abc.js ↓ 静态 JS 文件 ↓ 可以缓存 后端服务器 /my-account/abc.js ↓ /my-account ↓ 用户私人数据推理链① /my-account/abc.js ↓ ② 第一次请求 ↓ ③ X-Cache: miss ↓ ④ Cache-Control: max-age30 ↓ ⑤ 说明响应可以被缓存 ↓ ⑥ 30秒内再次请求 ↓ ⑦ X-Cache: hit ↓ ⑧ 证明该 URL 已经进入缓存 ↓ ⑨ 为什么 ↓ ⑩ 缓存可能根据 .js 判断它是静态资源 ↓ ⑪ 但后端可能把它当成 /my-account 动态页面 ↓ ⑫ 缓存层和后端对 URL 的解释产生差异 ↓ ⑬ 可能形成 Web Cache Deception完成实验点击go to exploit server 在body中插入我们想要对用户的网络欺骗代码欺取缓存session后登入账户拿到专属apiscriptwindow.locationhttps://0aea003004e6a85b80a50863004900f5.web-security-academy.net/my-account/xzy.js/script点击Deliver exploit to victim算是发送给用户然后访问以下urlhttps://0aea003004e6a85b80a50863004900f5.web-security-academy.net/my-account/xzy.js获得用户的api key 将其复制提交至submit solution 即可攻克工程极短 但是想要完全理解如何一步一步检测出缓存欺骗的可行性需要花些时间与理解我的攻克过程没能完成hit 可以参考以下视频借鉴学习https://www.youtube.com/watch?v9kGF1O9jyaA
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
