随着安检的提高，现在有很多防注入程序都屏蔽 and、1=1、1=2 类似这样的关键字，如果再使用这样的方法有时将不能探测到注入点了。
举例：http://www.somboy.com/news.asp?id=123
1、打开地址，我们可以看到是一个正常的页面。
2.、然后在地址后面加上-1，变成：http://www.somboy.com/news.asp?id=123-1，若返回的页面和前面不同，是另一个正常的页面，则表示存在注入漏洞，而且是数字型的注入漏洞
3、若在地址后面加上 -0，变成 http://www.somboy.com/news.asp?id=123-0，返回的页面和之前的页面相同，然后加上-1，返回错误页面，则也表示存在注入漏洞，而且是数字型的。
4、 若在地址后面加上’%2B’，变为：http://www.somboy.com/news.asp?id=123′%2B’，返回的页面和之前的相同； 再加上’2%2B’sb，地址变为：http://www.somboy.com/news.asp?id=123′%2Bsb，返回另一个正常的页面， 或者说未发现该条记录，或者错误，则表示存在注入漏洞，而且是文本型的。
原因分析：
如果SQL语句是这样执行的(数字)：select * from news where id=123
当在后面加上 -1 后，语句变为select * from news where id=123-1
但是SQL服务器在执行这条语句时会先进行运算123-1即为122，然后执行的是：select * from news where id=122
这样选出来的就是另外一条页面记录了。如果该页面存在，就是另一个页面；否则将会显示记录不存在，或者出错。这也同时表示程序未对输入的数据进行过滤，存在数值型的注入漏洞。
如果SQL语句是这样执行的(字符)：select * from news where id=’123′
在后面加上 ‘%2B’ 之后，语句变为：select * from news where id=’123′+” （%2B 是 + 的URL编码）
这时SQL服务器实际执行的是：select * from news where id=’123′，会返回同样的页面。
在后面加上 ‘%2B’sb之后，语句变为：select * from news where id=’123′+’sb’ （同样道理，SQL会先执行’123′+’sb’）
则SQL实际执行的是：select * from news where id=’123sb’，返回页面不存在，或者显错，就表示有文本型的注入漏洞。
