实战|bypass safedog最新版SQL注入探索

先添加一个单引号’，出现报错，可能存在注入点

and 1=1 被安全狗拦截了，说明部署成功。

那么，我们接下来得挨个测试看看是对哪里做了检测，触发了WAF的黑名单校验规则，从而被拦截。

测试 ?id=1 and 1=2 order by  3--+，直接被拦截

测试一下拦截位：

发现对order空格+by 这个组合中间出现空格就会被拦截，用上面的注释语句/*/123/**/，看能否绕过，还能过！

直接输入?id=1%27and/*/*123/**/1=2 union select 1,2,3--+，还是被拦截了。

还是在这里测试一下拦截位，如下：

发现对union空格+select 这个组合中间出现空格就会被拦截，用上面的注释语句/*/123/**/，被拦截掉了。这里进一步手动尝试变形，由于前面几步手动构造注释语句，一下绕过去了，我相信这一把应该也不需要很长时间测试。果不其然，在/*/*123/**/基础之上变形，构造/*/*!123%2b-/**/，成功绕过WAF检测。

这里直接查数据库名，还是会直接被拦截

经测试拦截位，直接把字段数字，改为database()会直接被拦截，去掉括号，就不拦截了。那说明对database()组合有拦截，对这个整体有检测，直接用上面的注释符看能否绕过，可行！

经过分块传输等各种测试WAF拦截位，一直处于被拦截，也FUZZ爆破过，但直到我们这里直接把union select删掉，发现对group_concat(table_name) from information_schema.tables where table_schema并没有出现拦截页面。此时一想，原来是上面的内联注释语句/*/*!123%2b-/**/无法绕过正则检测了，才被WAF拦截。那么，我们继续对注释语法进行变形，几番折腾，修改为/*//*//*!10448*/（经多次测试发现版本号必须有两位数字44在一块，其他三位为任意数字，咱就是说，有点玄学！！！），再测试，发现可以绕过了，成功查询出表名，如下：

这里我们查询字段名是否可以按照上面查询表名方法去绕过检测呢？试试看

是可行的，成功绕过，查询出字段名。

依旧按照上面查询表名、字段名方法来实验，如下：

也是可行的，成功绕过检测，查询出字段内容。

想到后面方便使用，依照上面的绕过手法，编写了个tamper脚本，经过验证，没毛病。

到了这里，针对bypass safedog最新版SQL注入探索就暂时告一段落了。

SQL注入漏洞的危害也涉及多个方面：

在云科安信的睚眦数字风险全栈防御系统中，就有针对SQL注入等安全威胁的防御模块。像本次实战探索的SQL注入攻击，就无法突破睚眦数字风险全栈防御系统的应用防护机制。

「睚眦」表单动态加固防护模块，通过“表单字段加密技术”，对表单提交参数名及参数值进行动态加密是混淆，如果数据包被劫持，看到的将不再是原始的参数及值，而是加密之后的密文。这些密文为动态加密混淆的，攻击者无法进行解密和修改，如若强行修改数据包将会被直接阻断。暴力破解、SQL注入等攻击需要对参数值进行不断地枚举以达到攻击的目的，使用了表单动态加固功能，攻击者将无法有效分析表单相关字段含义，也无法对参数名和参数值解密进行攻击。

在攻防实战中，经反复实践发现表单动态加固防御功能对0day攻击也有着天然的防御能力。Web应用层的0day攻击多数都是通过构造好的数据包直接对目标进行打击，而开启表单动态加固保护的应用，会对提交过来的数据包为明文参数非经过加密混淆后的密文，数据包会直接被阻断，大大降低了潜在的0day攻击风险。