HTTP绕WAF之浅尝辄止

0X00前言

最近参加重保，和同事闲聊时间，谈起来了外网，彼时信心满满，好歹我也是学了几年，会不少的。结果，扭头看完do9gy师傅的《腾讯 WAF 挑战赛回忆录》，就啪啪打脸了。说来惭愧，最近一段时间，拿到offer就开始飘起来了，现在悔不当初，于是就想写一篇关于这篇Http首部字段文章的"训诂篇"出来，一来当做知识巩固，二来算是完善些和首部字段相关的知识点（可会因为见识不足，导致遗漏）。毕竟，小白可能这方面了解不多，只了解Cookie和Agent这种常见类型的首部字段，却很少听过Accept-Encoding和Content-Encoding这类不太常用的首字部。

0X01基础知识

关于WAF的问题？

它是我们日常攻防演练必会遇见的，在IOS七层模型中，WAF分为网络层、应用层的，当然还有云 WAF（CDN+WAF）这新型类场景的。不同环境下我们绕过WAF的思路也是有所区别的，例如，对于传统的网络层 WAF，采用chunked编码（即对内容进行所谓的"加密"）即可绕过，下次遇见的时候，我们仍然尝试在网络层这一类型上进行尝试和探索。

存在于应用层的WAF，它们的处理引擎是经过前端到达Apache（或者是Nginx）完成 HTTP协议初步解析后，再转交给引擎处理的，这个时候网络层的绕过技术是无效的。这就需要我们去研究：对于一个 HTTP 请求，Nginx 解析了什么内容？交给后面的 PHP、ASP 又解析了什么内容？（探究到这个深度，就需要有良好的编程基础和协议基础，否则，后面及其吃力）。

至于最后的云WAF，我们可以简单的看成CDN加上软件WAF的结合体，既可以抗住DDos攻击，也可以过滤出部分简单的Payload攻击代码，甚至对流量也有一定的清洗作用。

HTTP首部的利用方式？

HTTP 请求头Content-Type的charset编码可以指定内容编码，在国内大多数都是UTF-8编码，但是攻击者在攻击的时候可以替换为 ibm037、 ibm500、cp875等不常用的"偏门"编码来绕过WAF的检测。我们也可以通过设置Content-Type头的值为application/x-www-form或者multipart/form-data;charset=ibm500,boundary=blah等进行绕过。

0X02首字部Encoding

关于Encoding，整个名称应该为Accept-Encoding；它在http协议中的作用是可以对内容（也就是body部分）进行编码。Accept-Encoding: gzip：表示它可以采用gzip这样的编码，从而达到压缩的目的。这样的话关于网络层的WAF是可以被绕过的，当然我们也可以使用其他的编码把内容搅乱或加密，以此来防止未授权的第三方看到文档的内容。当服务端接收到请求，并且从Header里拿到编码标识时，就可以选择其中一种方式来进行编码压缩，然后返给客户端。

浏览器发给服务器,声明浏览器（客户端）支持的编码类型解释

Accept-Encoding设置在请求头当中，会告诉服务器，我可以接受哪种编码压缩

Content-Encoding设置在响应头中，会告诉客户端，我用的是哪种编码压缩

​小提示：Encoding​的大概意思是：决定文件接收方将以什么形式、什么编码读取这个文件，指定服务器响应的 HTTP 内容类型；这两个header头都会影响服务器对于数据内容的传输格式类型（压缩算法）；文章：参考链接！

小提示：Accept-Encoding: deflate​但发现这种方法已经过时了，我们可以换成Accept-Encoding: gzip，发现上传成功。

加密绕过

分块传输绕过

如果在HTTP首字部中加入Transfer-Encoding: chunked。我们就可以利用这个报文采用了分块编码的方式绕过应用层面的WAF。原因的这时是通过POST请求报文中的数据部分，并对数据进行分块传输。每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的，也不包括分块数据结尾的，且最后需要用0独占一行表示结束（同时末尾需要以两个换行结束）。

小提示：上传失败的原因是没有分好考块，这种可以在绕过SQL注入或者XSS的时候进行尝试，不建议和上图一样对图片马进行尝试（关键是不好分块，效率低下）。

0X03首字部Pipeline

众所周知，HTTP协议是由TCP协议封装而来，当浏览器发起一个HTTP请求时，浏览器先与服务器通过TCP协议建立连接，然后发送HTTP 数据包给它，但是这里包含了一个Connection的字段，正常情况下该段的值为close。而且Apache等Web容器会根据这个字段决定是保持该 TCP 连接或是断开。当发送的内容太大，超过一个 HTTP 包容量，需要分多次发送时，值会变成keep-alive，即本次发起的 HTTP 请求所建立的TCP连接不断开，直到所发送内容结束Connection为close时停止。

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网页点击的结果却是下载到的一个文件或一张图片的原因。

特殊编码绕过

HTTP头里的Content-Type请求头一般有application/x-www-form-urlencoded，multipart/form-data，text/plain三种，其中multipart/form-data表示数据被编码为一条消息，页上的每个控件对应消息中的一个部分。当 WAF 没有规则匹配该协议传输的数据时则可被绕过。

利用特殊编码对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 发生不一致。

以 PHP 为例，我们写一个简单的测试脚本：

<?php
//用于将文件的内容读入到一个字符串中
echo file_get_contents("php://input");
//打印显示，一个变量的内容与结构
var_dump($_POST);
//打印显示，一个变量的类型的信息
var_dump($_FILES);
?>

双写上传描述行绕过

双写整个Part开头绕过

构造假的Part绕过

双写Boundary绕过

构造空Boundary绕过

构造空格+Boundary绕过

双写Content-Type绕过

Boundary+逗号绕过

小提示：Bypass WAF 的核心思想在于，一些 WAF 产品处于降低误报考虑，对用户上传文件的内容不做匹配，直接放行。事实上，这些内容在绝大多数场景也无法引起攻击。但关键问题在于，WAF 能否准确有效识别出哪些内容是传给$POST 数组的，哪些传给$FILES 数组？如果不能，那我们是否就可以想办法让 WAF 以为我们是在上传文件，而实际上却是在 POST一个参数，这个参数可以是命令注入、SQL 注入、SSRF 等任意的一种攻击，这样就实现了通用 WAF Bypass。

0X06首字部Filename

截断Filename绕过

首先将原始的带有脏数据的 payload 转换成文件上传包格式的协议：multipart/form-data，然后进行截断，如下图所示：

以上环境并未演示到另外一种基于 HTTP 协议特性绕过 WAF 的方法（实际上是基于 “协议未覆盖绕过” 方法，属于它的升级改造版）——filename 文件名混淆绕过。下面直接看漏洞银行大佬在视频中的实战利用演示。

空格+filename绕过

为了让 Payload 能够顺利解析，可以在 fliename="1.jpg"的等号前面添加空格，让 fliename 文件名无法解析，从而使得后面的php参数可被服务器解析执行，最终达到绕过 WAF 同时执行 pqyload 注入的目的：

双引号+filename绕过

另外此处也可以在 filename 前方添加双引号，也可以实现上述执行 payload 的目的：

0X07小结

通过上述学习，我们知道了关于HTTP首字部的一些知识点，进而通过利用该首字部的特点进行Fuzzing，最终达到绕过WAF的目的。当然上述结论难免存在不足，希望师傅们斧正。经过这几天的资料查找，我发现这些东西在CTF领域的研究，以及达到了登峰造极的地步。而且我们真正的去理解这些东西，可能需要掌握好一门语言和对HTTP协议有所了解（导致我的解释可能过于牵强dog），希望大家不要介意！

参考链接：

https://www.freebuf.com/news/193659.html

https://www.cnblogs.com/zzjdbk/p/13936278.html

https://github.com/LandGrey/abuse-ssl-bypass-waf

https://hakin9.org/bypassing-wafs-with-wafninja-free-course-content/

https://hacken.io/discover/how-to-bypass-waf-hackenproof-cheat-sheet/

https://www.notsoshant.io/blog/bypassing-waf-by-playing-with-parameters/

https://infosecwriteups.com/waf-bypasses-tearing-down-the-wall-d08fd0f8374a