今天到黑防站上去看看文章，可能出于“职业”习惯，看到?classid=1之类的东东就不由自主的想加点什么参数进去。
当在页面http://.cn/article/index.asp?classid=3&Nclassid=13加上①and 1=1和②and 1=2，都提示“处理 URL 时服务器上出错。请和系统管理员联络”，看起来象已经过滤了非法提交，IIS也关闭了错误提示，再加上一个③单引号’的时候，也出同样的错误提示，然而明显与前两个错误提示不同，因为前者显示了黑客防线的Logo才提示错误，后者则是一个空白的错误提示页。

这可是我从来没碰到过的特殊情况，到底能不能注入呢？

换个角度，从程序员的思路是怎么写这段程序的。首先，如果是用cint之类函数，那三种测试方法错误提示应该是完全一样的；如果没过滤的话，①②的结果应该是不一样的。排除了几种情况，最后觉得极可能是部分语句过滤，出现这种情况很可能是cint语句不小心放到SQL语句的后面，在SQL语句通过后，后面的语句报错。

虽然还不很确定实际的程序是怎么写的，但可以确定，这确实是一个注入点！

根据我写的《SQL注入漏洞全接触》，下一步就是判断数据库类型，因为错误提示都被屏蔽，只能通过系统表测试了，输入：

http://.cn/article/index.asp?classid=1 and (Select count(1) from sysobjects)>=0

提示出错，没出现Logo，说明是语句本身有错，极可能是表sysobjects不存在，也就是说数据库是Access，再拿一个Access应有的系统表试试（msysobjects在这个时候派不上用场，因为在Web下没有权限读取，SQL语句同样不能通过，所以，必须换个有权限的表如MSysAccessObjects），果然，出现了黑防的Logo，证实数据库确实是Access。
接下来的猜解就比较简单了，用(count(1) from admin)>=0测试出admin表存在，表中有username、password字段。本来以为下面就是用最普通的Ascii解码法猜解记录，小Case，没想到，一开始猜解，才发现这是最难啃的一块骨头：传统的Ascii对比中，无论条件是否成立，语句都是可以正确执行的，它是利用ASP的出错而非SQL语句的出错来发现错误的，在这个页面，不管你成不成立，都是显示一个Logo然后报错，根据无法做出判断。
冥思苦想了半个钟头，终于想出一种方法，让SQL语句有条件的报错，先看看语句：

http://.cn/article/index.asp?classid=1 and (select top 1 iif(asc(mid(username,1,1))>96,1,username) from admin)>0

写出这个语句的时候，连我自己都好崇拜我自己，哈哈，别吐，解释一下，asc(mid(username,1,1))这个都看得懂，取username第一位的ASCII码，大于96的话，select出数字1，小于等于96的话，select输出字符串username，然后，拿select出的值与0比较。
1与0都是数字型，当ASCII码大于96的时候，SQL语句不会出错；username则是字符型，当ASCII码小于等于96的时候，SQL语句会出错。所以，两种情况的出错提示是不同的，我们可以根据出错提示判断语句是否成立，从而逐步缩小每一位字符的范围，得出username的值。
于是，根据上面所说的方法，得出username的值为：chr(98)+ chr(114)+ chr(105)+ chr(103)+ chr(104)+ chr(116)=bright，password的值为chr(109)+ chr(105)+ chr(110)+ chr(103)+ chr(116)+ chr(105) + chr(97)+ chr(110)=mingtian，解码完成。