> 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/cheating-the-cache-via-cache-server-side-normalization.md).
# 通过缓存服务器端规范化欺骗缓存
面向 PortSwigger Web Security Academy 实验室的通过缓存服务器端规范化欺骗缓存笔记，包括利用流程、载荷测试、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`.
#### 技术：Fragment + Cross（带规范化）
构造一个 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/cheating-the-cache-via-cache-server-side-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.
