Normalize导致的WAF安全性研究

admin 2022年4月20日01:11:54安全文章评论5 views2527字阅读8分25秒阅读模式

1

Normalize概述


在上一篇文章中,我们简要描述了WAF检测的流程,详述了通过编码方式绕过WAF的思路。


传送门:编码导致的WAF安全性研究

本篇文章主要集中在WAF的Normalize阶段,分析Normalize阶段绕过WAF的思路。


Normalize是指把外部输入的数据进行标准化清洗,其中最重要的是把注释符里面的内容替换去除。

2

Normalize详解


2.1 对注释符的Normalize


一般WAF为了不影响后面正则匹配的结果,会对传入数据中的注释符进行过滤。基本的做法是把注释符整体内容替换为空格,典型的对注释符的Normalize过程如图2.1.1所示。
Normalize导致的WAF安全性研究
图2.1.1 Normalize处理注释符逻辑

从上图可以看出经过normalize处理之后的字符串可以去除无用字符的干扰,有利于下一步进行正则匹配。


不同语言的注释符是不一样的,但是WAF作为代理层,是需要兼容所有语言的。不同语言注释如表2.1所示。了解不同语言的注释符是掌握基于normalize绕过WAF的第一步。

表2.1 不同语言注释符理解
语言
注释
备注
SQL
/* 注释内容 */
多行注释
-- 注释内容 
单行注释,到换行结束
# 注释内容
单行注释,部分数据库支持,例如
mysql
JAVA
/* 注释内容 */
多行注释
// 注释内容
单行注释
python
# 注释内容
单行注释
''' 注释内容 '''
多行注释
php
/* 注释内容 */
多行注释
// 注释内容
单行注释
html
<!--注释内容-->
多行注释

不同语言的注释符不一样,WAF不会对所有注释符都进行normalize。第一步是需要找到能被WAF识别的注释符。一般来说/**/会被WAF识别,其他注释符可能不太一样。
Normalize导致的WAF安全性研究
图2.1.2 检查注释符是否能被WAF识别

2.2 注释歧义问题


注释符是与编程语言有关的,如果错误的把一种注释当成另一种注释,就可能出现注释歧义问题。

最典型的注释歧义问题就是“你以为的注释符其实不是注释符”。/**/在SQL语句中是属于多行注释,但是对于html来说,就没有特殊含义。所以,我们可以通过下面的方式来绕过WAF,如图2.2.1所示。这里最关键的是通过/**/来注释想要执行的xss代码。
Normalize导致的WAF安全性研究
图2.2.1 通过/**/来绕过XSS检测

与这种思路相似的,可以用于绕过上传检测。如图2.2.2所示。/**/对于一般的代码来说确实是注释符,但是如果/**/根本就不在代码的开始标签中,则可能导致基于注释歧义的WAF绕过问题。
Normalize导致的WAF安全性研究
图2.2.2 通过/**/来绕过webshell内容检测

2.3 注释伪造问题


注释的种类有很多种,能被WAF正确识别的并不完整,而且WAF对代码的执行顺序也可能导致多个注释同时存在时出现绕过的可能。

在测试某WAF时,验证此WAF能识别/**/多行注释,但是不能识别--的单行注释。那么下面的逻辑可能就会被WAF识别错误,如表2.3.1所示。从中可以清晰的看出数据库真实执行的代码和WAF检测到的代码是不一样的,因为normalize的原因导致部分关键字被删除了,从而可以绕过WAF。

表2.3.1 多重注释导致的WAF识别错误
原始数据
Normalize之后
数据库引擎
1 union -- /*
select md5(1)  -- */
1 union -- 
1 union select md5(1)

用实际的WAF来查看效果,如图2.3.1所示。

http://192.168.6.183/test/sqli.php?&id=-1%20union%20--%20/*%0aselect%20--%20*/%0a%20pass%20from%20user

Normalize导致的WAF安全性研究
图2.3.1 通过多重注释绕过WAF进行联合查询

这种绕过的关键在于通过引入“不起作用的/**/”来欺骗WAF,与此类似也可以通过定义变量的形式来达到类似的效果,如图2.3.2所示。

http://192.168.6.183/test/[email protected]`/*`%20union%20select%[email protected]`*/`%20from%20user

Normalize导致的WAF安全性研究
图2.3.2 通过伪造注释绕过WAF

曾几何时,某WAF就出现过一个很经典的绕过方式(相信懂的小伙伴肯定秒懂我说的是谁,当然现在已经修复了),如图2.3.3所示。这里面最主要的是通过两个不存在的参数来引入多行注释/**/。
Normalize导致的WAF安全性研究
图2.3.3 通过构造不存在参数带入/**/绕过WAF

2.4 内联注释问题


内联注释是属于mysql特有的一种特性,并不适用于其他数据库。内联注释的使用方式有两种,如表2.4.1所示。


表2.4.1 内联注释的使用方式
类型
内联注释
数据库引擎解析
普通注释
/*union*/select
select
内联注释
/*!union*/select
union select
内联注释
/*!50001union*/select
union select

内联注释已经被广泛使用于绕过WAF,目前主流的WAF对内联注释基本上都做了比较好的防御,如图2.4.1所示。
Normalize导致的WAF安全性研究
图2.4.1 两种内联注释均能被WAF识别并拦截

这里有一个问题是内联注释/*!50001注释内容*/中的数字可以允许有哪些?实际上内联注释里的数字只要小于当前mysql版本号就可以。例如假设当前mysql版本为5.7.34,那么小于等于50734的五位数字都可以执行。部分WAF在Normalize阶段对这块的处理并不严格也会导致绕过,如图2.4.2所示。
Normalize导致的WAF安全性研究
图2.4.2 绕过WAF的内联注释数字

3

总结


可能有的小伙伴会问,WAF在normalize阶段,除了会对注释符进行替换之外,还会不会有其他的处理动作?一般来说,normalize阶段还可能会有的动作包括

1) 把所有的不可见字符替换为空格

2) 把百分号%替换为空(兼容mssql+asp的场景)

3) 把上传文件的内容替换为空(上传文件较大,部分WAF为了提高效率,会在正则之前先把上传文件的内容替换为空)

只要是WAF进行了操作,那么就可能会有被利用的空间,我们站在WAF设计的角度来分析WAF可能出现的安全性问题,就会发现其实可利用的点还有很多Normalize导致的WAF安全性研究

本文以安全研究为目的,不针对特定WAF产品,请勿对号入座。

Normalize导致的WAF安全性研究

原文始发于微信公众号(Beacon Tower Lab):Normalize导致的WAF安全性研究

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月20日01:11:54
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  Normalize导致的WAF安全性研究 http://cn-sec.com/archives/926959.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: