> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/zh/web/web-cache-deception/web-cache-deception-via-cache-server-normalization.md).
# 通过缓存服务器端规范化进行 Web 缓存欺骗
面向 PortSwigger Web Security Academy 实验室的通过缓存服务器端规范化进行 Web 缓存欺骗笔记，包括利用流程、载荷测试、Burp Suite 验证和修复上下文
### 利用缓存服务器规范化进行 Web 缓存欺骗
#### 实验目标
从用户处获取 \*\*API 密钥\*\* **carlos** 通过利用一个 **URL 规范化行为** （应用程序与缓存服务器之间的解释差异）。/ 可用连接： **wiener:peter**.
#### 初始观察
我们测试静态后缀以触发缓存：
* 测试请求：
```bash
GET /my-account~test.js
```
根据某些字符会有不同的响应，服务器接受：
* `#`
* `?`
* `%23` （用于 URL 编码 `#`)
* `%3f` （用于 URL 编码 `?`)
#### 有趣的端点也被缓存
资源目录似乎也被隐藏：
```http
GET /resources/ HTTP/2
```
这很有用，因为我们将尝试将缓存指向 `/resources` 同时让应用将某条路由解释为 `/my-account`.
#### 技巧：片段 + 交叉（带规范化）
构造一个 URL，使应用程序继续处理 **/my-account**，而缓存将该序列规范化/解释为，最终得到 **/resources**.
测试：
```bash
GET /my-account#/../resources
# 编码版本（这里“最能通过”的那个）
GET /my-account%23%2f%2e%2e%2fresources
```
关键点： **缓存服务器会接受 URL 编码版本**，这会触发预期的行为。
#### 利用：强迫受害者缓存该页面
由于利用服务器，受害者被重定向到陷阱 URL：
{% code overflow="wrap" %}
```javascript
```
{% endcode %}
#### 结果
一旦受害者访问过该 URL，便会恢复从缓存中提供的资源，并获取 \*\*carlos API 密钥\*\*，从而完成实验。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/zh/web/web-cache-deception/web-cache-deception-via-cache-server-normalization.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
