ASP中数据库的安全是一个很严肃的问题。很多代码的编写者意识到了这类问题，并且小心翼翼地对他们认为有问题的地方做了补救，但常见的情况是要么没有穷尽所有的可疑地点，要么这种补救逻辑上有误。对于一个耐心且嗅觉灵敏的攻击者来说，这种意义上的补救措施和没有任何补救措施没有本质上区别。
　　下面罗列的是一些可能出现的问题：有些是常见易犯的错误，有些根本就是逻辑上有问题。看看你是不是也这样写过？对于攻击者而言，倒着看这些东西，应该对寻找漏洞有点帮助，更为完整一点的检测方法，请等我的关于黑/白盒分析和自动化测试文章。

一、令人疑惑的过滤方式

　　典型例子是不管不顾地对所有的输入变量都去掉单引号，或者是把单引号替换成合法的两个单引号，例如：

id = replace(request.querystring("id"), "'", "")
str = replace(request("someinput"), "'", "''")

　　现在很明了的是，第一个做法很有可能是错误的。因为引起SQL Injection的不总是单引号，再扩大一点，引起问题的不是任何单独的符号，这样子的过滤，有些冤枉单引号了。正确的利用注入，重要的一点是闭合前面的一句SQL查询语句——往往是得先正确地闭合前面一个条件，因为我们可能会在同一句里面引入新的条件，补救措施只要破坏注入条件应该就可以了，但是考虑到其复杂性（下面会说），最好还是较为完整的限制一下输入的字符种类。
　　第二个看起来是没有什么问题的，但潜在的会带来一些隐患。这很容易给人造成的一个错觉是，我对输入的字符串已经很有效的做过处理了，以后使用没有什么问题。这句话没有错，对字符串来说这样做也是很正确的，但是他扮演了一个不光彩的角色，试想一下，如果过滤后的字符串放进了数据库，而后续的语句有直接拿出来使用的，这种对前面过滤的依赖性，是不是正确的呢？
　　也许较好的做法应该是，针对具体的情况来确定过滤的准则。
　　常见的输入变量有三种：数字，字符串还有集合。对于数字型的输入变量，简单调用一下判断函数即可，见得到的代码中，凡是检查了这类变量的，几乎都正确。对于字符串型的来说，基本上在插入到生成的SQL语句时，前后都有单引号，如果仅从破坏注入条件来看，把单引号替换成两个单引号应该问题不大。同理的，如果是一个字符串的集合，也可以简单的用这种方法。而如果是数字的集合，情况可能稍微麻烦一点，至少你得允许数字、逗号或许还有空格之类的符号在输入中正常出现，这样子的过滤规则可能显得复杂，不过你可以借鉴一下dvBBS6.1打过补丁后的版本，总的来说，对于已经发现的过滤漏洞而言，他们还是补得比较好的。
　　对于第二句话，至少现在不能说它说错的，我们留待后面解决。

二、获取的数据值得信赖吗？

　　其实这样子说范围显得有点大，一下子涉及到很多方面，一个例子一个例子地举来看好了。
　　首先是关于选择过滤数据的问题。一直以来，我们认为凡是用户输入的东西，都要经过适当的处理。没错，但真正的是否都做到呢？随便找个抓包的工具，比如Ethereal，看看在你用IE提交表单或者是打开连接的时候，都提交了什么。或者，简单一些，打开NetAnt编辑一个任务，在协议标签中，看看那个“自定义提交者”和“用户代理”的选项。
　　我想你已经明白了，对方可以自己定制的东西不仅仅是GET或POST过来的数据！如果所有的用户都规规矩矩地用浏览器，确实不用防备这么严，如果对方不这么老实，在取服务端变量或Cookie的时候可要小心了，没有任何人能够保证你获得的数据是合法的。对于Cookie而言，很多程序都出过问题，所以以前强调得比较多，至于另外的，关注的人可能比较少一点，但你是否看过或者写过这样的代码：
（责任编辑：欣欣裴）