程序体（3）

　　有了上面的过滤函数您可以在任何需要过滤的地方应用过滤函数直接使用就可以了。这就使我们的修复工作大大的简化了。

　　另外，我想在这里再次多提醒一下，一些站点的UBB在进行小的表情图标转化时也会出现过滤问题，由于很隐蔽所以不容易发现：

　　如：

　　我们标签内的文字进行修改，

　　不知道各位看懂没，前一个单引号用来中和程序提供的左引号，第二个单引号用来中和闭合的右引号，这样程序输出就为：

　　＜img src=’img/0001.gif’ onerror=****:alert(); alt=’’＞

　　如果图片不存在，那么将激活onerror标签执行脚本程序。对于已经过滤了单引号的站点在这里用双引号一样可以完成。对于过滤了****字段的，只用alert()也完全可以。所以说要过滤就要过滤完全，别给攻击者留下一丝机会。

　　防范SQL Injection 漏洞攻击

　　可以这样说，这里似乎是整篇文章的重点了.SQL Injection 漏洞攻击的的多样化也使得我们在程序防护上不得不想的更多一些。面对SQL Injection 的强大”攻势”，我们到底该过滤哪些？

　　一些常用的危险字符有

　　’ 　　 数据库字段判别封闭

　　-- 　　某些数据库注释标志

　　#　　 某些数据库注释标志

　　“　　 可能导致程序出错

　　\　　 跨越目录

　　3221143836nicode　　编码的特征字符

　　$　　可能用于变量标注

　　/ 和\ 　　一样

　　NULL　　 小心“空“录入的危险，可能导致数据库或系统处理报错，利用报错构造溢出.

　　空格和’一起，构造sql injeciton

　　? = &　　 如果存在二次参数传递，可能改写querystr。

　　(1) 从最一般的.SQL Injection 漏洞攻击来看：用户名和密码上的过滤问题，如：

　　提交：用户名为：’or’’=’ 用户密码为：’or’’=’

　　从程序出发，我们完全可以得出，数据库在执行以下操作

　　Sql=” SELECT * FROM lUsers WHERE Username=’’or’’=’’ and Password = ’’or’’=’’”

　　这样一来，这样，SQL 服务器将返回 lUsers 表格中的所有记录，而 ASP 脚本将会因此而误认为攻击者的输入符合 lUsers 表格中的第一条记录，从而允许攻击者以该用户的名义登入网站。对此类注入的防范似乎简单的很：

　　利用以下程序就可以实现，程序体（4）

　　strUsername = Replace(Request.Form(“Username“), “’’“, “’’’’“)
　　strPassword = Replace(Request.Form(“Password“), “’’“, “’’’’“)