hacktricks/pentesting-web/http-response-smuggling-desync.md

114 lines
7.8 KiB
Markdown
Raw Normal View History

# HTTP 响应劫持 / Desync
2022-04-28 16:01:33 +00:00
<details>
<summary><strong>从零开始学习 AWS 黑客技术,成为专家</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTEHackTricks AWS 红队专家)</strong></a><strong></strong></summary>
2022-04-28 16:01:33 +00:00
支持 HackTricks 的其他方式:
* 如果您想看到您的**公司在 HackTricks 中做广告**或**下载 HackTricks 的 PDF**,请查看[**订阅计划**](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 来**分享您的黑客技巧**。
2022-04-28 16:01:33 +00:00
</details>
**本文技术取自视频:[https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)**
2021-11-05 20:59:42 +00:00
## HTTP 请求队列 Desynchronisation
2021-11-05 20:59:42 +00:00
首先,这种技术**滥用了 HTTP 请求劫持漏洞**,因此您需要了解这是什么:
2021-11-05 20:59:42 +00:00
这种技术与常见的 HTTP 请求劫持的**主要区别**在于,**不是通过向受害者的请求添加前缀来攻击**,而是**泄露或修改受害者接收到的响应**。这是通过**发送两个完整请求来使代理响应队列脱节**,而不是发送一个半请求来滥用 HTTP 请求劫持。
2021-11-05 20:59:42 +00:00
这是因为我们将能够**使响应队列脱节**,从而将**受害者的合法请求的响应发送给攻击者**,或者**在响应中注入攻击者控制的内容**。
2021-11-05 20:59:42 +00:00
### HTTP 管道 Desync
2021-11-05 20:59:42 +00:00
HTTP/1.1 允许**请求不同资源而无需等待前一个请求**。因此,如果**中间有代理**,则代理的任务是**维护与发送到后端的请求和从后端返回的响应的同步匹配**。
2021-11-05 20:59:42 +00:00
然而,存在一种问题,即响应队列的脱节。如果攻击者发送了一个 HTTP 响应劫持攻击,并且对**初始请求和劫持的请求的响应立即响应**,则劫持的响应不会被插入到受害者响应的队列中,而将**被视为错误而被丢弃**。
2021-11-05 20:59:42 +00:00
因此,需要**劫持的请求需要更长时间才能在后端服务器中处理**。因此,当劫持的请求被处理时,与攻击者的通信将结束。
2021-11-05 20:59:42 +00:00
在这种特定情况下,如果**受害者发送了一个请求**,而**劫持的请求在合法请求之前得到响应**,则**劫持的响应将发送给受害者**。因此,攻击者将**控制受害者“执行”的请求**。
2021-11-05 20:59:42 +00:00
此外,如果**攻击者然后执行一个请求**,而**受害者的合法响应**在**攻击者请求之前被回答**。则**受害者的响应将发送给攻击者****窃取**受害者的响应(例如可能包含头部**Set-Cookie**)。
2021-11-05 20:59:42 +00:00
2023-08-03 19:12:22 +00:00
### 多重嵌套注入
2021-11-05 20:59:42 +00:00
与常见的**HTTP 请求劫持**的另一个**有趣的区别**是,在常见的劫持攻击中,**目标**是**修改受害者请求的开头**,以执行意外操作。在**HTTP 响应劫持攻击**中,由于您**发送完整请求**,因此您可以**在一个有效负载中注入数十个响应**,这将**使数十个用户脱节**,这些用户将**接收**到**注入的响应**。
2021-11-05 20:59:42 +00:00
除了能够更轻松地**在合法用户之间分发数十个漏洞**外,这也可以用于在服务器上引起**拒绝服务**。
2021-11-05 20:59:42 +00:00
### 攻击组织
2021-11-05 20:59:42 +00:00
如前所述,要滥用这种技术,需要**第一个劫持的消息**在服务器中**需要花费很长时间来处理**。
2021-11-05 20:59:42 +00:00
如果只想**尝试窃取受害者的响应**,则这**耗时请求足够**。但如果要执行更复杂的攻击,则这将是攻击的常见结构。
2021-11-05 20:59:42 +00:00
首先是**滥用 HTTP 请求劫持**的**初始**请求,然后是**耗时请求**,然后是**1个或多个有效负载请求**,其响应将发送给受害者。
2021-11-05 20:59:42 +00:00
## 滥用 HTTP 响应队列 Desynchronisation
2021-11-05 20:59:42 +00:00
### 捕获其他用户的请求 <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
2021-11-05 20:59:42 +00:00
与已知的 HTTP 请求劫持有效载荷一样,您可以**窃取受害者的请求**,但有一个重要区别:在这种情况下,您只需要**发送的内容在响应中反映****不需要持久存储**。
2021-11-05 20:59:42 +00:00
首先,攻击者发送一个包含**最终 POST 请求和反映参数**的有效负载,以及一个较大的 Content-Length
然后,一旦**初始请求**(蓝色)被**处理****同时**正在处理**耗时请求**(黄色),**来自受害者的下一个请求**将被**追加到队列中,紧跟在反映参数后面**
2021-11-05 20:59:42 +00:00
然后,**受害者**将**接收**到**耗时请求的响应**,如果**同时** **攻击者发送了另一个请求**,则**反映内容请求的响应将发送给攻击者**。
2021-11-05 20:59:42 +00:00
## 响应 Desynchronisation
2021-11-05 20:59:42 +00:00
到目前为止,我们已经学会了如何滥用 HTTP 请求劫持攻击来**控制**客户端将**接收**的**请求**,以及如何**窃取本应发送给受害者的响应**。
2021-11-05 20:59:42 +00:00
但是,仍然可以**进一步脱节**响应。
2021-11-05 20:59:42 +00:00
有一些有趣的请求,如**HEAD**请求,规定**响应体内不应包含任何内容**,且应(必须)**包含请求的 Content-Length**,就像**GET 请求一样**。
2021-11-05 20:59:42 +00:00
因此,如果攻击者**注入**一个**HEAD**请求,如下图所示:
2021-11-05 20:59:42 +00:00
然后,**一旦蓝色请求被响应给攻击者**,下一个受害者请求将被引入队列:
2021-11-05 20:59:42 +00:00
然后,**受害者**将**接收**到**HEAD**请求的**响应**,其中**将包含 Content-Length 但没有任何内容**。因此,代理**不会将此响应发送给受害者**,而将**等待**一些**内容**,实际上将是**黄色请求的响应**(也是攻击者注入的):
2021-11-05 20:59:42 +00:00
2023-08-03 19:12:22 +00:00
### 内容混淆
2021-11-05 20:59:42 +00:00
根据前面的示例,知道您可以**控制**受害者将**接收**的请求的主体,以及**HEAD** **响应**通常在其标头中包含**Content-Type 和 Content-Length**,您可以**发送如下**请求来**在不使页面容易受到 XSS 攻击的情况下**在受害者中**引发 XSS**
2021-11-05 20:59:42 +00:00
### 缓存投毒
2021-11-05 20:59:42 +00:00
滥用先前评论的响应 Desynchronisation 内容混淆攻击,**如果缓存存储了受害者执行的请求的响应,并且此响应是导致 XSS 的注入响应,则缓存将被投毒**。
2021-11-05 20:59:42 +00:00
包含 XSS 负载的恶意请求:
2021-11-05 20:59:42 +00:00
向受害者发送包含指示缓存存储响应的标头的恶意响应:
2021-11-05 20:59:42 +00:00
{% hint style="warning" %}
请注意,在这种情况下,如果**“受害者”是攻击者**,那么他现在可以在**任意 URL 中执行缓存投毒**,因为他可以**控制将被缓存的 URL**与恶意响应。
2021-11-05 20:59:42 +00:00
{% endhint %}
### Web 缓存欺骗
2021-11-05 20:59:42 +00:00
这种攻击类似于前一种,但**攻击者将在缓存中存储受害者信息**,而**不是在缓存中注入有效负载**
2021-11-05 20:59:42 +00:00
2023-08-03 19:12:22 +00:00
### 响应分割
2021-11-05 20:59:42 +00:00
这种攻击的**目标**是再次滥用**响应** **脱节**,以便**使代理发送 100% 由攻击者生成的响应**。
2021-11-05 20:59:42 +00:00
为了实现这一点,攻击者需要找到 Web 应用程序的一个端点,该端点**在响应中反映一些值**,并且**知道 HEAD 响应的内容长度**。
2021-11-05 20:59:42 +00:00
他将发送一个**利用**如下的**漏洞**
2021-11-05 20:59:42 +00:00
在第一个请求被解决并发送回攻击者后,**受害者的请求被添加到队列中**
2021-11-05 20:59:42 +00:00
受害者将作为响应**接收到** **HEAD** 响应 + 第二个请求响应的内容(包含反映数据的部分):
2021-11-05 20:59:42 +00:00
然而,请注意,**反映数据的大小符合 HEAD 响应的 Content-Length**,这**在响应队列中生成了一个有效的 HTTP 响应**。
2021-11-05 20:59:42 +00:00
因此,**第二个受害者的下一个请求**将**接收到** **完全由攻击者制作的响应**。由于响应完全由攻击者制作,他还可以**使代理缓存响应**。