改良版的UDP协议QUIC将成为未来谷歌网站新标准

By jmdcw

曾多次写过关于IN方式的注入，可能程序员并不看俺的文章，所以嘛。。。。今天受小林之托，在看一段源码时，又见到了这个漏洞，闲来无事，就来现一下吧，高手请飘过。

一般IN方式的利用代码如下：

dim id
id=request.form("id")
Conn.Execute("delect from 表名 where name='"&name&"' and id in ("&id&")")

对于这种漏洞，我以前的做法是用IIF函数，它的语法是：IIF( 逻辑表达式 , 为真时的表达式 , 为假时的表达式 )，意思就是当逻辑表达式为真时，比如1＝1，就返回“为真时的表达式”，如果表达式为1＝2，那么就返回“为假时的表达式”。假如我构造的语句 是：“IIF(((select len(user) from[表]where id=某个用户ID值)=猜测值),1,2)”，其中“某个用户的ID值”是欲猜测用户的ID值，如果为真返回的就是1，否则返回的就是2，然后将值传递 到id中就是 ：id in(1)或id in(2)，这样，从这两个之中找出一个真，据此，来暴力破解出所要猜测的值。

除了IIF还有没有别的方法呢？当然有了，就是直接加括号，比如在上面的ID中直接提交语句：

1) and (select len(user) form[表] where id=某个用户的id值)=猜测值 and 1 in(1

这样用括号就匹配了IN中的括号，以后只需更改提交语句中的猜测值就可以猜测出用户名的长度了。

如果这个漏洞出现在SQL数据库中，那么就更简单了，先来用这样的语句看一下是否是SQL数据库

1) and user>0 and 1 in(1

如果返回了错误，并有用户名，那么就是SQL数据库了，然后再试一下多句执行方式：

1);另一个sql语句--

当然，如果要利用IN漏洞快速注入，个人感觉，还是用俺以前写过的注入转发页比较快一些。