参数化介绍

在前面的两篇文章中，我们已经对编码和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的实现逻辑，所以关于完全参数化和局部参数化的对比和优劣势大家可以自行脑补。这两种方式会带来一些不一样的绕过风险，这将是本文后续分析的核心思路。

参数污染问题

参数污染（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输出参数的示例