本文的主要从绕过WAF过程中需求留意的人物、点动身，测验了解它们的运作，构建一个简略的常识结构。假设对本文中的任何常识点有任何对立主意或是定见、主张，请提出来，这对笔者是非常重要的，笔者也会非常感谢。
首要，WAF分为非嵌入型与嵌入型，非嵌入型指的是硬WAF、云WAF、虚拟机WAF之类的；嵌入型指的是web容器模块类型WAF、代码层WAF。非嵌入型对WEB流量的解析完全是靠自身的，而嵌入型的WAF拿到的WEB数据是现已被解析加工好的。所以非嵌入型的受攻击机面还涉及到其他层面，而嵌入型从web容器模块类型WAF、代码层WAF往下走，其对立变形报文、扫操作绕过的才能越来越强，当然，在布置保护本钱方面，也是越高的。
 
HTTP报文包体的解析
咱们先来讨论一个问题。HTTP恳求的接收者在接收到该恳求时，会关怀哪些头部字段，以及会依据这些头部字段做出对request-body进行相应得解析处理。说实话，要搞清这些东西，更好仍是检查web容器的源码，但笔者现在还没做到这一步，在这里仅能依据自身得认知提及一些头部字段。这些头部字段的联系，笔者以为能够总结为如下：
Transfer-Encoding（Content-Encoding（Content-Type（charset（data））））
Transfer-Encoding
想了解Transfer-Encoding自身的含义，请检查文章“它不但不会削减实体内容传输巨细，乃至还会使传输变大，那它的效果是什么呢？” ，这篇文章对了解本末节非常重要。 Apache+php对chunked类型的HTTP恳求的处理太怪了。RFC2616中说明晰，客户端或服务器，收到的HTTP报文中，假设一起存在chunked与Content-Length，则必定要疏忽掉content-length（这一点也天经地义，很好了解），而在apache中反而不能短少。尽管笔者没有阅读过Apache的源码，但从这一点能够推理出，Apache自身是不支持解析chunked的（关于Apache来说，因为没有解析HTTP恳求chunked的代码逻辑，所以必定要从content-length中检查该报文的长度，而chunked或许是被PHP解析了的，所以存在这两个头部必定要一起存在的怪现象）。这一定论也很好地解说了一些让笔者不解的现象，如使用chuncked能够绕过安全狗Apache。 经过shodan搜索相关服务器，笔者简略测验一下，关于常见中间件、言语与chuncked的联系有如下参阅：
ASPX
PHP
Java
Apache
X
Y
Nginx
Y
Y
IIS
Y
Y
Tomcat
X
那关于chunked，能够有什么使用思路呢？ 思路一，结构一个chunked恳求体，测验绕过WAF。其间能够涉及到使用chunked自身的一些标准、特性。 比方，假设WAF会解析chunked，但参加一些chunked的扩展，WAF就解析不了。 反过来，脑洞一下，假设WAF认识到了解析chunked时应该疏忽这些扩展，那么在Tomcat下咱们是不是能够使用它一下。
POST /test HTTP/1.1
Host: 127.0.0.1:8081
Content-Type: application/x-www-form-urlencoded;
Content-Length: 29
Content-Transform: chuncked
3;&user='+'1'='1&
foo
0
(CRLF)
使用思路二，解析不一致导致的问题，Apache+PHP对客户端的恳求解析非常“杰出” 之前落叶纷飞说到的思路 使用分块传输吊打一切WAF
POST /sql.php?id=2%20union HTTP/1.1
......
Transfer-Encoding: chunked
1
aa
0
(CRLF)
相似还有下面这种
POST /test/2.php HTTP/1.1
Host: 192.168.17.138
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 20
9
user=root
(CRLF)
尽管页面回来的是400，但后台都是履行成功了的。
Content-Encoding
它与Transfer-Encoding本质上的差异便是，Transfer-Encoding能够被 *** 中的各个实体解析并改动，而Content-Encoding在传输过程中不应该、不会被改动的。 该字段在Response中比较常见，而在Request中，或许你一辈子都很难遇到。除非运维人员对Web服务器做了相关装备，使得服务器能够辨认并解析客户端Request恳求的Content-Encoding 头部字段，不然Web服务默许是不会辨认该字段的。笔者想尽量写得全一点，尽管这个字段看起来鸡肋、无用，但能够作为一个或许的打破测验点。
Content-Type
Web容器应该不怎么关怀Content-Type这个字段，后台言语则会辨认该字段并进行对应的数据解析。而咱们使用该字段的话，主有从以下思路动身：后台言语会辨认哪些类型的Content-Type，这些Content-Type对咱们绕WAF有没有用。 PHP默许会处理application/x-www-form-urlencoded、multipart/form-data两种。而JAVA后台关于multipart/form-data类型Content-Type的辨认处理，需求凭借三方库或是结构，默许情况下是无法处理的，但现在一般都用结构，而结构或许默许情况下就会辨认并处理这类型的恳求。 后台接收到application/x-www-form-urlencoded恳求的数据时，会自己解码一次，假设开发人员自己又解码一次或屡次，就形成了两层编码、多重编码。 关于multipart/form-data，非嵌入型的与模块类型的WAF，都只能自己辨认并解析区别字段内容，所以在这一块你能够发挥自己幻想，进行各种骚操作来进行绕过，可是，你应该要承认你当时所要绕过的WAF是不是真的做了这块的内容辨认。笔者的意思是说，假设它遇到这种类型Request，仅仅对Body内容进行悉数的规矩匹配，而不会解分出其间的表单内容，那你或许就没必要进行那些骚操作了。实际上，有的非嵌入型WAF便是这么“懒”。multipart/form-data的相关骚操作能够参阅Protocol-Level Evasion of Web Application Firewalls
Charset
charset是被添加在Content-Type字段后边的，用来指明音讯内容所用的字符集，它也仅被后台言语所关怀。
• application/x-www-form-urlencoded;charset=ibm037• multipart/form-data; charset=ibm037,boundary=blah• multipart/form-data; boundary=blah ; charset=ibm037

[1] [2] [3] [4]  黑客接单网