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

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的检测，从而给企业造成巨大的伤害。 然而，这种情况并不仅仅会发生在WAF上。锦行科技的安全团队也会持续进行分析研究，去发现这些导致安全防护失灵的“大坑”，帮助政府、企业在保障用户体验同时，也能兼顾业务系统的安全性，达到一个合理的平衡。 锦行信息安全订阅号，提供一手安全资讯（微信ID：jeeseensec），敬请关注！

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/