TryHackMe - HTTP Request Smuggling

学完、打完后的复习

HTTP 1

这部分比较简单，直接略过

HTTP2请求走私

首先要了解HTTP2的结构，与HTTP1之间的一些差异

HTTP2中不再使用CRLF来作为字段的边界限定，而是在二进制中直接通过长度、名字、值长度、值，来确认边界

而这里教导的主要场景是在前端代理使用HTTP2，而后端使用HTTP 1.1

虽然HTTP2并不会处理Content-Length和Transfer-Encoding，但在上述场景下，前端代理将把http2转为http1.1然后转发给后端处理。

所以一旦我们为http2请求添加CL或TE，并在post form添加http 1.1的请求头，即常规http1的请求走私打法，前端代理将http2转http1.1交给后端后，我们的走私请求将会逃出来

CRLF

除了CL和TE，还有另一种方法在上述场景中实现请求走私，就是CRLF，通过在http2请求头中的请求头里面注入CRLF并构造走私请求payload，那么在前端代理转发给后端时依然能够实现http请求走私

在某些代理实现中，每个用户将获得自己的后端连接，以将他们的请求与其他用户分开。每当发生这种情况时，攻击者将无法影响其他用户的请求。乍一看，如果局限于我们自己的连接，我们似乎做不了多少事情，但我们仍然可以通过前端代理走私请求并取得一些结果。由于我们只能将请求走私到我们的连接，因此这种情况通常称为请求隧道。

泄露内部标头

这一点也非常简单，前提是存在回显点，后面的靶机中有这个例子

绕过前端代理限制

同上，前端代理做了访问控制，但后端没有，我们就可以通过请求走私来绕过前端代理，将走私请求送到后端，此时我们再次发起http请求 接住走私请求以获得走私的响应

WebSocket 走私

第一种就是简单的欺骗前端代理

Sec-WebSocket-Version: 777
Connection: Upgrade
Upgrade: websocket

将Sec-WebSocket-Version字段设为目标不支持的版本，此时，前端代理不验证后端是否升级websocket成功（code 101）和失败（code 426），所以只有前端代理与我们使用websocket进行通信，而前端代理到后端依然使用http进行通信

我们就可以在websocket中携带恶意http请求头以实现走私

请注意，某些代理甚至不需要存在 WebSocket 端点即可使该技术发挥作用。我们所需要做的就是欺骗代理，让其相信我们正在建立与 WebSocket 的连接，即使事实并非如此。看看如果您尝试发送以下有效负载会发生什么（请确保在 Burp 中的有效负载后添加两个换行符）

绕过安全代理

那么，如果前端代理会验证后端是否升级成功（code 101），在这里，thm教导我们可以寻找SSRF来帮助我们做到这一点。

通过ssrf访问我们托管的http服务器，当我们触发ssrf时，目标访问我们的恶意http服务器，我们就可以控制我们的http服务器返回 code 101，表示升级成功，此时前端代理就会认为升级成功，后续攻击者到前端代理都将使用websocket通信，而事实上后端仍然使用http

HTTP 浏览器异步

keep-alive: 允许对多个 HTTP 请求和响应重复使用单个 TCP 连接

http 管道： 如果后端服务器启用了 HTTP 管道，它将允许同时发送两个请求和相应的响应，而无需等待每个响应。区分两个请求和一个大请求的唯一方法是使用 Content-Length 标头

HTTP 浏览器异步利用链接 XSS，也比较简单，略过

El Bandito

这里是打完靶机后的复盘，只有细节部分

nmap

我们在8080中有一个SSRF

8080存在websocket走私，前端代理会验证websocket是否升级成功

结合前面的ssrf，我们就可以完全照搬前面thm教导的技巧来绕过前端代理的验证

最后payload如下图，我们可以得到一组凭据以及靶机的第一个flag：

最后回到80端口，存在http2请求走私，通过CL或者是http2请求头CRLF注入来实现走私，结合/send_message端点可以发送消息，借此通过走私来获取受害者标头，通过/getMessages来获取回显信息。

最后一个flag则在标头中