参数化导致的WAF绕过研究

littlebird

参数化导致的WAF绕过研究​
1
参数化介绍
在前面的两篇文章中，我们已经对编码和normalize这两个阶段可能造成的WAF绕过进行了分析。按照之前文章的分析结论，参数化是整个WAF工作过程中的又一个重要的阶段，在这个阶段中同样存在可以绕过WAF的思路。

往期回顾：
传送门：编码导致的WF安全性研究
传送门：Normalize导致的WAF安全性研究

经过normalize之后，WAF收到的数据已经是比较干净的数据了，在进行正则匹配之前还需要对HTTP请求的参数进行处理。参数化的过程中主要包含的工作包括：
1） 提取HTTP请求中的不同部分内容，包括GET参数、POST参数、文件上传内容、COOKIE等。
2） 对参数进行解析，把参数转化为键值对的形式。标准的转化如图1.1所示。

​

编辑
图1.1 HTTP请求参数化demo样式

但是并不是所有的WAF都会把请求进行完整的参数化，早期WAF会把GET和POST的每一个请求都提取出来进行匹配，但是现在的WAF更喜欢通过局部参数化的方式来进行比较。与完全参数化比较不同，局部参数化主要是不再把GET、POST、Header这些字段转化为对应的键值对，而是把整个当成一个大的字段进行匹配。

​

编辑
图1.2 完全参数化与局部参数化对比

本文主要目的不是为了说明WAF的实现逻辑，所以关于完全参数化和局部参数化的对比和优劣势大家可以自行脑补。这两种方式会带来一些不一样的绕过风险，这将是本文后续分析的核心思路。

2
参数污染问题
参数污染（HTTP Parameter Pollution，简称HPP）应该是参数化中最直观可见的问题，可以用一句简单的话来说明参数污染问题就是“在HTTP请求中同时传递两个名字相同的参数服务器会怎么接收参数，WAF会怎么接受参数“。如图2.1所示。

​

编辑
图2.1 在请求中同时传递两个同名参数par

不同服务器对于参数污染的处理方式是不一样的，从网上找一个关于服务器对参数污染的总结表格，如图2.2所示。

​

编辑
图2.2 不同服务器处理参数污染的结果

既然服务器对参数污染问题的处理方式都不统一，那么可以预见WAF对于参数污染同样可能存在不一样的处理逻辑。

如果WAF在处理参数污染的时候，取到的值是多个重复值中的某一个，则可能造成在asp.net/iis环境中存在绕过的方式。如图2.3所示。

​

编辑
图2.3 通过参数污染来拆分注入的关键字

在这种模式中，WAF获取的值是“-1 union/*”或者”*/select 1,2,3”，这两个数值单独来看都不具有威胁性，所以WAF不会拦截。但是在asp.net/iis的环境下，后端接收到的值是“-1 union/*,*/select 1,2,3 ”，这就是一个标准的联合查询语句，也就可以绕过WAF进行注入了。

目前的WAF很少受参数污染问题的影响的主要原因是目前WAF多数情况下是通过局部参数化的方式来进行匹配，也就是说最终进行正则的是整个GET的值“par=-1%20union/*&par=*/select+1,2,3”，这样的payload是很容易被WAF识别和联合查询的注入的。

聪明的小伙伴一定会想到一个问题就是，如果在GET中传入参数par，然后又在POST中传入参数par，是不是会导致参数污染的问题。我们在aspx.net/iis的环境中来实验一下这个想法，如图2.4，图2.5所示。通过下面两张图可以看出，POST中传入的参数par并不能和GET中传入的参数par相互污染。
​编辑


图2.4 最简单的aspx.net输出参数的示例

​

编辑
图2.5 通过POST不能污染GET中的参数

参数污染已经是一种很古老的技术，目前WAF也基本上都会防御对应的绕过情况，单纯通过参数污染已经很难绕过WAF。

3
参数位置问题
WAF对于不同位置参数的正则是不一样的，比如对于最常见的id=1 and 1=1这种payload，在某知名狗WAF上测试来看，如果是GET请求会被拦截，但是如果是POST请求则不会拦截。如图3.1，图3.2所示。

​

编辑
图3.1 GET请求中的and 1=1要拦截

​

编辑
图3.2 POST请求中的 and 1=1不拦截

这种问题其实不算是一种严格意义上的绕过，WAF对不同位置的防护策略不一样是一种正常的配置，一般来说基于传输数据的复杂性，不同位置的防护策略如图3.3所示。这种比较是针对于同一种攻击方式（比如SQL注入），如果是某个位置才特有的攻击类型（比如文件上传）则不适用于此比较方式。所以，如果我们在SQL注入的过程中遇到某个WAF，第一个考虑的是这里的参数是不是可以通过POST或者Cookie来进行传参，如非必要尽量不要在GET中进行SQL注入。

​

编辑
图3.3 不同位置WAF防护策略等级

更高级的，本人在fuzz一些绕过某狗的方式时也发现一些更有意思的现象。下面的两张图中对应的payload是完全一样的，一种是普通POST数据包，一种是上传POST包。我们可以看到WAF在处理这两个payload的时候有不一样的结果，在上传类型的POST包中竟然可以达到无限制绕过WAF的效果。如图3.4，图3.5所示。

​

编辑
图3.4 普通POST包被拦截

​

编辑
图3.5 上传类型的POST包不拦截并可以无限制注入

4
大参数问题
大参数是指字符个数特别多的参数，攻击者通过可以通过向正常的某个参数中注入大量无用字符，从而使得该参数成为大参数的效果。

大参数问题很早以前就已经被安全研究人员提出，关于大参数问题该不该防御一直都是安全领域中存在争议的一个话题。这里面争议的焦点就是性能和安全的争议，如图4.1所示。

​

编辑
图4.1 关于大参数问题的争议

如果http请求很大，如果再对请求进行正则匹配确实会降低性能，很多对延迟要求较高的系统确实不能接受这样的性能损耗。但是保留大参数的问题又会成为攻击者可利用的点，我们还是以某狗来说明大参数带来的绕过问题。

一个标准的联合查询语句，如图4.2所示，这种是会被拦截的。

​

编辑
图4.2 标准联合查询语句被拦截

我们在%27中间加入大量无用字符，大约5000个以上吧。就可以发现某狗不拦截了，并且后端正确执行的SQL语句返回联合查询的数据，如图4.3所示。

​

编辑
图4.3  添加无用之后字符之后的大参数不拦截

那么大参数问题就真的无解了吗？答案是否定的。对大参数问题主要是要解决性能和安全的平衡点，一个网站需要大参数的地方应该不多，通过人工填写或者机器学习的方式找到需要大参数的地方单独例外处理就好了。

5
畸形参数问题
畸形参数一般是指格式非规范的参数，这种格式一般是指上传数据包。对于一般的POST请求，对应的POST BODY一般有两种类型，分别是application/x-www-form-urlencoded和multipart/form-data，如图5.1，图5.2所示。对于后端服务器接收到的数据，这两种类型的请求是没有区别的。

​

编辑
图5.1 标准POST请求

​

编辑
图5.2 multipart/form-data类型请求

multipart/form-data类型的请求主要是依据boundary来对请求进行分割，然后拆分成键值对的形式。相比于传统POST请求，multipart/form-data类型的请求格式更加复杂，也就提供了更多绕过WAF的可能。

标准的multipart/form-data类型的POST包主要分成两种类型的数据，一个是普通类型的数据，一个是上传类型的数据，如图5.3所示。一般来说，WAF对于普通数据的防护都要严格一些，对于上传类型的数据都要宽松一些。为什么会有这种逻辑呢？上传的文件一般比较大，如果对大文件进行大量正则会导致严重影响效率，而且对上传文件的文件内容匹配SQL注入等类型的攻击也没有任何实际意义。

​

编辑
图5.3 对比普通数据和上传数据

在某次对目标网站的授权渗透测试过程中遇到的一个真实案例，目标存在WAF而且规则极严，通过代码审计的方式找到了反序列化的漏洞，但是反序列化的payload要被WAF拦截。最终通过构造畸形的POST数据包达到绕过WAF的效果，如图5.4所示。

​编辑

图5.4 畸形POST包传递

相比于传统的POST数据包，我在后面增加了”filename    =1.png”，这也是绕过WAF的关键。站在服务器的角度，因为filename后面有空格，这不是一个上传文件的数据包，这还是一个普通的数据$_POST[form_data]；站在WAF的角度，因为normalize的原因会忽略一些空格，WAF认为这是一个上传的数据包$_FILE[form_data]。由于WAF对上传文件的内容检测要相对宽松一些，所以就造成了绕过。

上面的demo只是畸形参数中的一种利用方式，真正的畸形参数还有很多，如表5.1所示。

表5.1 常见畸形传参方式

​

编辑

6
总结
本文旨在描述一些参数化过程中可能导致的WAF绕过问题，并不针对特定WAF类产品。要想绕过WAF主要是要找到WAF在解析参数时和服务器在解析参数时的区别，站在WAF设计人员的角度来想WAF绕过的问题，问题就变简单了。
​