HTTP Response Smuggling / Desync
本帖的技术来自视频： https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
HTTP 请求队列去同步
首先，这种技术利用了 HTTP 请求走私漏洞，所以你需要知道这是什么：
这种技术与常见的 HTTP 请求走私的主要区别在于，不是通过添加前缀来攻击受害者的请求，而是泄露或修改受害者收到的响应。这是通过发送两个完整的请求来去同步代理的响应队列，而不是发送一个半请求来利用 HTTP 请求走私。
这是因为我们将能够去同步响应队列，使得受害者的合法请求的响应被发送给攻击者，或者通过在响应中注入攻击者控制的内容。
HTTP 管道去同步
HTTP/1.1 允许请求不同的资源而不需要等待之前的请求。因此，如果中间有一个代理，那么代理的任务是保持发送到后端的请求和来自后端的响应的同步匹配。
然而，去同步响应队列存在一个问题。如果攻击者发送一个 HTTP 响应走私攻击，并且对初始请求和走私请求的响应立即返回，那么走私响应不会被插入到受害者响应的队列中，而是作为错误被丢弃。
因此，需要走私请求在后端服务器中处理的时间更长。因此，当走私请求被处理时，与攻击者的通信将结束。
如果在这种特定情况下，受害者发送了一个请求，而走私请求在合法请求之前被响应，那么走私响应将被发送给受害者。因此，攻击者将控制受害者“执行”的请求。
此外，如果攻击者随后执行一个请求，而对受害者请求的合法响应在攻击者请求之前被回答，那么对受害者的响应将被发送给攻击者，窃取对受害者的响应（例如，可能包含Set-Cookie头）。
多重嵌套注入
与常见的HTTP 请求走私相比，另一个有趣的区别是，在常见的走私攻击中，目标是修改受害者请求的开头，以便执行意外的操作。在HTTP 响应走私攻击中，由于你发送完整的请求，你可以在一个有效载荷中注入数十个响应，这将去同步数十个用户，这些用户将接收被注入的响应。
除了能够更容易地在合法用户之间分发数十个漏洞，这也可以用来导致服务器的拒绝服务。
漏洞组织
如前所述，为了利用这种技术，需要第一个走私消息在服务器中处理的时间很长。
如果我们只是想尝试窃取受害者的响应，那么这个耗时的请求就足够了。但如果你想执行更复杂的漏洞，这将是漏洞的常见结构。
首先是初始请求，利用HTTP 请求 走私，然后是耗时的请求，最后是一个或多个有效载荷请求，其响应将被发送给受害者。
利用 HTTP 响应队列去同步
捕获其他用户的请求
与已知的 HTTP 请求走私有效载荷一样，你可以窃取受害者的请求，有一个重要的区别：在这种情况下，你只需要发送的内容在响应中被反射，不需要持久存储。
首先，攻击者发送一个有效载荷，包含一个带有反射参数的最终 POST 请求，并且有一个大的 Content-Length。
然后，一旦初始请求（蓝色）被处理，而耗时的请求（黄色）正在被处理时，来自受害者的下一个请求将被附加在反射参数之后：
然后，受害者将收到对耗时请求的响应，如果在此期间攻击者****发送了另一个请求，反射内容请求的响应将被发送给他。
响应去同步
到目前为止，我们已经学习了如何利用 HTTP 请求走私攻击来控制客户端将要接收的响应，以及如何窃取原本属于受害者的响应。
但仍然可以进一步去同步响应。
有趣的请求如HEAD请求被指定为不应在响应体内包含任何内容，并且应（必须）包含请求的 Content-Length，就像GET 请求一样。
因此，如果攻击者注入一个HEAD请求，如下图所示：
然后，一旦蓝色请求被响应给攻击者，下一位受害者的请求将被引入队列：
然后，受害者将收到来自HEAD请求的响应，该响应将包含一个 Content-Length，但没有任何内容。因此，代理不会将此响应发送给受害者，而是等待一些内容**，实际上将是对黄色请求的响应（也由攻击者注入）：
内容混淆
根据前面的例子，知道你可以控制请求的主体，而该请求的响应将被受害者接收，并且HEAD 响应通常在其头部包含Content-Type 和 Content-Length，你可以发送如下请求以在受害者中引发 XSS，而页面并不容易受到 XSS 攻击：
缓存中毒
利用之前提到的响应去同步内容混淆攻击，如果缓存存储了受害者执行的请求的响应，并且该响应是一个导致 XSS 的注入响应，那么缓存就被毒化了。
包含 XSS 有效载荷的恶意请求：
包含指示缓存存储响应的头的恶意响应：
请注意，在这种情况下，如果**“受害者”是攻击者**，他现在可以在任意 URL 上执行缓存中毒，因为他可以控制将被缓存的 URL与恶意响应。
Web 缓存欺骗
此攻击类似于前一个，但攻击者将受害者信息缓存到缓存中，而不是在缓存中注入有效载荷：
响应分割
此攻击的目标是再次利用响应 去同步，以便使代理发送 100% 由攻击者生成的响应。
为了实现这一点，攻击者需要找到一个反射某些值到响应中的 Web 应用程序端点，并知道 HEAD 响应的内容长度。
他将发送一个漏洞，如下所示：
在第一个请求被解决并发送回攻击者后，受害者的请求将被添加到队列中：
受害者将收到的响应是HEAD 响应 + 第二个请求响应的内容（包含部分反射数据）：
然而，请注意反射数据的大小与 HEAD 响应的 Content-Length 相符，这在响应队列中生成了有效的 HTTP 响应。
因此，第二位受害者的下一个请求将接收作为响应完全由攻击者构造的内容。由于响应完全由攻击者构造，他还可以使代理缓存该响应。
Last updated
