目录
https://infosecwriteups.com/waf-bypasses-tearing-down-the-wall-d08fd0f8374a
（一）WAF
0x01 分类
0x02 Waf工作模式
2.1 关闭模式
对某个站点使用关闭模式，到这个站点的流量就感受不到WAF的存在。一般的做法，是解绑域名，再到web服务上绑定该域名。
2.2 监听模式
既过规则，也会直接传递给web服务
2.3 防护模式
直接过规则，不会直接传递给web服务
0x03 工作原理
详情参考：https://www.cnblogs.com/realjimmy/p/12937247.html#:~:text=WAF%E5%85%A8%E7%A7%B0%E5%8F%ABWeb,Application%20Firewall%EF%BC%8C%E5%92%8C%E4%BC%A0%E7%BB%9F%E9%98%B2%E7%81%AB%E5%A2%99%E7%9A%84%E5%8C%BA%E5%88%AB%E6%98%AF%EF%BC%8C%E5%AE%83%E6%98%AF%E5%B7%A5%E4%BD%9C%E5%9C%A8%E5%BA%94%E7%94%A8%E5%B1%82%E7%9A%84%E9%98%B2%E7%81%AB%E5%A2%99%EF%BC%8C%E4%B8%BB%E8%A6%81%E5%AF%B9web%E8%AF%B7%E6%B1%82%2F%E5%93%8D%E5%BA%94%E8%BF%9B%E8%A1%8C%E9%98%B2%E6%8A%A4%E3%80%82
0x04 工作过程
4.1 解析HTTP请求
对接收到数据请求流量时会先判断是否为HTTP/HTTPS请求，之后会查看此URL请求是否在白名单之内，如果该URL请求在白名单列表里，直接交给后端Web服务器进行响应处理，对于不在白名单之内的对数据包解析后进入到规则检测部分。
4.2 匹配规则
解析后的数据包会进入到检测体系中进行规则匹配，检查该数据请求是否符合规则，识别出恶意攻击行为。
4.3 防御动作
如果符合规则则交给后端Web服务器进行响应处理，对于不符合规则的请求会执行相关的阻断、记录、告警处理。
不同的WAF产品会自定义不同的拦截警告页面，在日常渗透中我们也可以根据不同的拦截页面来辨别出网站使用了哪款WAF产品，从而有目的性的进行WAF绕过。
4.4 记录日志
0x05 关于WAF的问题
- 它是我们日常渗透测试中必会遇见的，在IOS七层模型中，WAF分为网络层、应用层的，当然还有云 WAF（CDN+WAF）这新型类场景的。不同环境下我们绕过WAF的思路也是有所区别的，例如，对于传统的网络层 WAF，采用chunked编码（即对内容进行所谓的"加密"）即可绕过，下次遇见的时候，我们仍然尝试在网络层这一类型上进行尝试和探索。
- 存在于应用层的WAF，它们的处理引擎是经过前端到达Apache（或者是Nginx）完成 HTTP协议初步解析后，再转交给引擎处理的，这个时候网络层的绕过技术是无效的。这就需要我们去研究：对于一个 HTTP 请求，Nginx 解析了什么内容？交给后面的 PHP、ASP 又解析了什么内容？（探究到这个深度，就需要有良好的编程基础和协议基础，否则，后面及其吃力）。
- 至于最后的云WAF，我们可以简单的看成CDN加上软件WAF的结合体，既可以抗住DDos攻击，也可以过滤出部分简单的Payload攻击代码，甚至对流量也有一定的清洗作用。
1、以Cloudflare为例
假设，您有一个搜索字段并尝试了一个payload，例如 <script>alert(1)</script>。现在，当你检查时，网站阻止了你，你需要现在回去。像这样的东西(图1-5）：
在这里，您应该假设后面有防火墙阻止您输入任何过滤字符。这就是为什么它被正确实施！好的，这就是 BYPASSES 发挥作用的地方。旁路只是绕过过滤器的技术。我们将使用一个普通的有效载荷来了解它是如何绕过 WAF 的。让我们看看这个有效载荷：
%22%3E%3Cimg%20src%3Dx%20onerror%3Dalert(1)%3E这与“><img src=x οnerrοr=alert(1)>”相同，但有时对其进行编码可能会起作用。现在的问题是，为什么 WAF 接受这个有效载荷，而这也与“警报”有关。简单地理解如下：WAF 有一些定义的规则，它们遵循包含过滤字符和单词的清单。因此，如果未在该清单中过滤，则此处的简单编码将起作用。然而，如今 WAF 相当先进，它们甚至可以过滤base-64 编码。无论如何，这就是我们的有效载荷绕过 WAF 的基本思想。
https://infosecwriteups.com/waf-bypasses-tearing-down-the-wall-d08fd0f8374a
2、HTTP首部的利用方式
HTTP 请求头Content-Type的charset编码可以指定内容编码，在国内大多数都是UTF-8编码，但是攻击者在攻击的时候可以替换为 ibm037、 ibm500、cp875等不常用的"偏门"编码来绕过WAF的检测。我们也可以通过设置Content-Type头的值为application/x-www-form或者multipart/form-data;charset=ibm500,boundary=blah等进行绕过。
(二）首字部Encoding
关于Encoding，整个名称应该为Accept-Encoding；它在http协议中的作用是可以对内容（也就是body部分）进行编码。Accept-Encoding: gzip：表示它可以采用gzip这样的编码，从而达到压缩的目的。这样的话关于网络层的WAF是可以被绕过的，当然我们也可以使用其他的编码把内容搅乱或加密，以此来防止未授权的第三方看到文档的内容。当服务端接收到请求，并且从Header里拿到编码标识时，就可以选择其中一种方式来进行编码压缩，然后返给客户端。
- 浏览器发给服务器,声明浏览器（客户端）支持的编码类型解释
Accept-Encoding设置在请求头当中，会告诉服务器，我可以接受哪种编码压缩
Content-Encoding设置在响应头中，会告诉客户端，我用的是哪种编码压缩0x01 加密绕过
Accept-Encoding: deflate但发现这种方法已经过时了，我们可以换成Accept-Encoding: gzip，发现上传成功,如图2-1。
0x02 分块传输绕过
如果在HTTP首字部中加入
Transfer-Encoding: chunked。我们就可以利用这个报文采用了分块编码的方式绕过应用层面的WAF。原因的这时是通过POST请求报文中的数据部分，并对数据进行分块传输。每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的，也不包括分块数据结尾的，且最后需要用0独占一行表示结束（同时末尾需要以两个换行结束）,如图2-2。
需要注意的是，拆分完成后，有0占位一行，来结束拆分，后面还有两行空行，用来结束数据包请求，如图2-3。如果删掉后面两空行，请求变为死循坏，服务器是不做任何相应的。
0X03 首字部Pipeline
pipeline绕过是利用http协议的管道化技术，http遵循请求响应模型，比如发送一个A请求，则会返回A请求的响应，如果当发送一个请求的同时发送多个http请求，如果waf只对第一个请求进行检查判断，就可以绕过后面http请求的数据检查,如图2-4.
- 利用这种方法需要将第一个请求的connection字段值改为 keep-alive
Connection: keep-alive
0X04 首字部Disposition
Content-Disposition的具体原理：它是WAF的一个规则，针对文件上传主要是对那个地方去做防护的，所以需要混淆去绕过。
由于该协议对 PHP 对解析存在缺陷、使得如果一行有多个 filename 字段值，则PHP构造的Web Server会取最后的filename值进行解析。Web Server最终可以得到的文件名是1.php，但是某些WAF只会判新第一个filename的值，因此 WAF 对上传的文件的过滤检测功能会被黑客绕过，并且这里的form-data是可有可无的类型，就是去掉它也不会影响Web Server获取filename的名称（如下所示）：
Content-Disposition: form-data; name="file1"; filename="1.txt";filename="1.php";虽是如此，但filename的编码还会被HTTP请求Content-Type头中charset所影响；Web Server可以根据这个值进行响应的解码处理。这些都有可能被一些人稍微做点手脚，便可以绕过不少WAF的文件上传过滤检测。可能有的师傅会说，那怎么测试啊？这个其实就见仁见智了，我通常会自己搭建一个环境进行Fuzzing字典的黑盒测试；如果是代码审计和CTF功底好的师傅，可能就直接测试一些漏洞点了。
0X05 首字部Typer
Content-Type：一般是指网页中存在的Content-Type，用于定义网络文件的类型和网页的编码，决定文件接收方将以什么形式、什么编码读取这个文件，这就是经常看到一些Asp网页点击的结果却是下载到的一个文件或一张图片的原因。
Demo:
<?php
//用于将文件的内容读入到一个字符串中
echo file_get_contents("php://input");
//打印显示，一个变量的内容与结构
var_dump($_POST);
//打印显示，一个变量的类型的信息
var_dump($_FILES);
?>5.1 特殊编码绕过
HTTP头里的Content-Type请求头一般有application/x-www-form-urlencoded，multipart/form-data，text/plain三种，其中multipart/form-data表示数据被编码为一条消息，页上的每个控件对应消息中的一个部分。当 WAF 没有规则匹配该协议传输的数据时则可被绕过。
- 将头部Content-Type改为multipart/form-data; boundary=69 然后设置分割符内的Content-Disposition的name为要传参数的名称。数据部分则放在分割结束符上一行，如图5-1
- 利用特殊编码对payload进行转义，从而绕过WAF对特殊关键词的过滤。
- 该方法的思路主要围绕：multipart/form-data进行，主要针对于 POST 参数的，对于需要在GET参数位置触发的恶意漏洞影响不大。说起multipart/form-data 的作用，我们知道HTTP 协议POST请求，除了常规的 application/x-www-form-urlencoded 以外，还有 multipart/form-data 这种形式，就是为了解决上传文件场景的问题下文件内容较大且内置字符不可控的问题而准备的。multipart/form-data 格式也是可以传递POST参数的。对于Nginx+PHP的架构，Nginx 实际上是不负责解析 multipart/form-data 的 body 部分的，而是交由 PHP 来解析，因此 WAF 所获取的内容就很有可能与后端的 PHP 发生不一致。
5.2 双写上传描述行绕过
5.3 双写整个Part开头绕过
5.4 双写Boundary绕过
5.5 双写Content-Type绕过
总结：
Bypass WAF 的核心思想在于，一些 WAF 产品处于降低误报考虑，对用户上传文件的内容不做匹配，直接放行。事实上，这些内容在绝大多数场景也无法引起攻击。但关键问题在于，WAF 能否准确有效识别出哪些内容是传给$POST 数组的，哪些传给$FILES 数组？如果不能，那我们是否就可以想办法让 WAF 以为我们是在上传文件，而实际上却是在 POST一个参数，这个参数可以是命令注入、SQL 注入、SSRF 等任意的一种攻击，这样就实现了通用 WAF Bypass。
参考资料
How to Bypass WAF. HackenProof Cheat Sheet - Hacken
554
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
