绕过waf之分块传输

在渗透测试的过程中，遇到WAF也就意味着，我们不能使用安全工具进行渗透测试，因为如果一旦触碰了WAF的规则，轻则丢弃报文，重则拉黑IP，所以，我们需要手工对WAF进行绕过，我们需要对WAF有一个简单的了解。

WAF的分类

嵌入型
- 硬件行WAF：以硬件的形式部署在链路中，支持多种部署，当串联到链路中时可以拦截恶意流量，在旁路监听时，只记录攻击，不进行拦截
- 软件型WAF：以软件的形式安装在服务器中，可以直接检测服务器是否存在webshell，是否有文件被直接创造过等
- 云WAF，一般以反向代理的形式工作，通过配置NS，或者NNAME记录，使得网站的请求报文优先经过WAF主机，经过WAF主机过滤以后，将被认为无害的请求报文发送给实际网站服务器进行请求，可以认为是带防护功能的CDN
嵌入型

网站的内置WAF，直接将WAF嵌入到代码中，相对来说，自由度极高，网站内置的WAF与业务更加契合

如何判断是否有WAF

手动检查

手动在域名后面加一个不存在的id参数，并且加上很明显的sql语句，查看服务器的回应。

SQLmap检测

如果网站存在WAF，sqlmap会有提示。

WAF的工作原理

WAF(Web Application Firewall) 可以用来屏蔽常见的网站漏洞攻击，如SQL注入，XML注入、XSS等。WAF针对的是应用层而非网络层的入侵，从技术角度应该称之为Web IPS。

WAF的主要难点是对入侵的检测能力，尤其是对Web服务入侵的检测，WAF最大的挑战是识别率。对于已知的攻击方式，可以谈识别率，但是对于未知的攻击手段，WAF是检测不到的。

基于规则匹配的WAF

目前市面上大多数的WAF都是基于规则的WAF。即WAF对接数据收到的包进行正则匹配过滤，如果正则匹配到与现有漏洞知识库的攻击代码相同，则认为这个恶意代码，从而对于进行阻断。所以，对于基于规则匹配的WAF，需要每天都及时更新最新的漏洞库

对于这种WAF，它的工作过程是这样的：解析HTTP请求——>匹配规则——>防御动作——>记录日志

具体实现如下：

解析http请求：协议解析模块
匹配规则：规则检测模块，匹配规则库
防御动作：：return 403 或者跳转到自定义界面，或者不返回任何数据，或者拉黑IP
日志记录：记录到elk中 (E=Elasticsearch(基于 Lucene),L=Logstash,K=Kibana)

WAF的绕过

从WAF工作的机制我们可以知道，只有在WAF解析HTTTP请求或者WAF匹配规则两方面绕过。

域名转换为IP

有些WAF设置的是针对域名的防护，在有些时候，我们可以尝试将域名改成ip地址有可以绕过WAF的防护。

WAF解析HTTP请求阶段绕过

参考此文章

https://blog.csdn.net/qq_36119192/article/details/82942185#%E4%B8%80%E6%AC%A1HTTP%E8%AF%B7%E6%B1%82%E7%9A%84%E8%BF%87%E7%A8%8B

我们可以知道HTTP请求过程中的各种数据

分块编码（Transfer-Encoding）绕过WAF

数据的分段传输

我们都知道http协议是由TCP协议封装而来的应用层协议。我们和服务器之间的每次http交互都要进行三次握手和四次挥手。那么，服务器端怎么判断客户端传来的数据已经发送完了，然后断开这次tcp连接呢？我们客户端在发送给服务器端报文中有一个Connection 字段，一般这个值为 close。也就是说这次数据传输完成了，服务器就会断开这次tcp连接。但是，当我们要传送的数据量比较大，一次传输不能传输完成时，该如何办呢？这就要用到数据的分段传输了。

当使用分段传输时，请求头中的 Connection字段的值为：keep-alive ，最后一个数据包的Connection字段值为：close。

当服务器端收到Connection值为keep-alive的数据包时，会先将它存储在一个缓冲区中，当收到 Connection 值为 close 的数据包时，即表明这次数据传输完成！

通常，Content-Length 消息头字段表示数据的长度。数据的长度很重要，因为服务器端需要知道哪里是应答消息的结束，以及后续应答消息的开始。然而，使用分段传输，数据分解成一系列数据块，并以一个或多个块发送，这样可以发送数据而不需要预先知道发送内容的总大小。通常数据块的大小是一致的，但也不总是这种情况。于是我们分段进行传输数据的每一次请求的Content-Length是我们这次请求的大小，当服务器端收到 Connection值为close的请求消息后，就会把之前的Content-Length加起来，即是我们请求的数据的总大小了。