前言

今天在团队群里看到so师傅转发了一篇c0ny1师傅的延时分块传输文章，读完之后马上跪了。原来我一直研究的HTTP协议还可以五马分尸，打一个sleep的操作。想想前天晚上速读的TCP/IP图解，嗯，我又有信心抓包看一下，这HTTP是如何sleep传输的了。

先把文章链接扔在这：https://mp.weixin.qq.com/s/mgxLsBL9GTzRMh7wd0UOoQ

开始

话不多说，十分的巧妙。最近本来就在研究绕过NIDS的姿势，本来中午刚刚下载了c0ny1师傅的插件，这晚上就看到了这篇文章，我说怎么下载插件的时候发现c0ny1师傅的这个插件4、5天前才更新呢。原来是更新了这一硬姿势。

经典的靶机testphp.vulnweb.com，直接一个POST报文上插件干上。不多BB赶时间背单词睡觉。

当然了，少不了wireshark。因为这一定是TCP层的分块，Burp根本没法分析。一个干净的host IP地址的过滤。

插件分块发送。

绕过的根本原理？

直接说个人截至目前研究的斗胆猜测结果吧：这种分块延时传输Bypass WAF的方式根本上就是把一个HTTP报文分成了多个TCP数据包发送，然后整个HTTP报文发送结束的时间间隔不能大于服务器保持TCP连接等待HTTP数据发送完毕的时间。但要大于WAF保持TCP连接等待HTTP数据的时间。打了这个时间差，绕过了WAF的检测。

更严谨一点说：至少在WAF保持TCP连接时间之内发送的HTTP数据报文中不能出现WAF可检测的攻击载荷。（这要看WAF是拼接完整个HTTP报文再检测恶意内容，还是边拼接便检测）

所以我猜测，这种绕过方式与Chunked并没有直接关系，而只是TCP分块传输HTTP数据的长延时，使WAF不堪资源的重负而放弃了该TCP流的检测。

因为：从分块传输的报文中可以分析，客户端与服务端三次握手之后，第一个TCP数据包只有一段请求头： POST / HTTP/1.1\r\n，没有任何特征表示这是一个chunked报文。如果是只有HTTP报文使用chunked编码才等待的话 ， 那第一个TCP数据包发送这个POST / HTTP/1.1\r\n后，服务端就应该要返回一个HTTP响应了。

但如果服务端在读完整个HTTP请求头后，判断是不是chunked，再进行等待数据或者返回响应的操作，那么我这种说法就不对了。

思路拓展

对于建立TCP连接的双方来说，服务端等待的是客户端一个完整的HTTP协议报文，没错，就是要有一个HTTP请求头和HTTP请求体，并且要完全遵循HTTP协议，\r\n不能少，格式更不能错，否则服务器会直接返回一个400响应码的错误请求的响应回来。

所以，只要我们分块不断发送的数据报文符合HTTP协议的规定，那么服务器会保持这个TCP连接一直等待我们HTTP数据传输完毕。与此同时，WAF也在等待我们的数据，并对其中的内容做恶意载荷的检测。

但，当WAF与服务器对一个TCP连接数据传输保持的时间不同时，例如WAF最多只等待15s数据传输完毕，而服务器可以等待30s。那么WAF就会先放弃对该TCP流的连接保持，而服务器仍然在等客户端发送来一个完全合法的或者是一个错误的HTTP报文过来。因此，在30s内，HTTP报文发送完毕，恶意载荷已经发送，而WAF早已经放弃了这一TCP流的检测，形成了Bypass。

因此，从HTTP数据切分成多个TCP数据进行延时分块传输的角度来讲，不仅限于POST、Chunked，HTTP数据包可以任意组织进行延时发送。

从Bypass的角度讲：同时要保证在时间上将WAF耗死之前不要被WAF检测拼接检测到恶意载荷（这要看WAF是拼接完整个HTTP报文再检测恶意内容，还是边拼接便检测）。

那么，是否可以幻想这种工具，延时打HTTP报文，前20s只发送无关紧要的字符，后面快速发出攻击载荷，打死WAF，并且不让WAF活着的时候检测到攻击载荷？以上所有想法有待测试。

最后

只是自己的一些想法，里面不免有很多漏洞。个人在网络上的理解还是比较浅显，上面的理论后面会抽出时间来做证明。如果您看到了这篇文章，并且发现了我的问题或者有自己的一些想法，欢迎留言讨论。