近来，网络上的SQL Injection 漏洞利用攻击，JS脚本，HTML脚本攻击似乎逾演逾烈。陆续的很多站点都被此类攻击所困扰，并非像主机漏洞那样可以当即修复，来自于WEB的攻击方式使我们在防范或者是修复上都带来了很大的不便。HOOO...... 一个站长最大的痛苦莫过于此。自己的密码如何如何强壮却始终被攻击者得到，但如何才能做到真正意义上的安全呢?第一，别把密码和你的生活联系起来;第二，Supermaster的PWD最好只有你自己知道;第三，绝对要完善好你的网站程序。然而怎样才能完善，这将是我们此文的最终目的。
安全防护，如何做到安全防护?想要防护就要知道对方是如何进行攻击。有很多文章都在写如何攻下某站点，其实其攻击的途径也不过是以下几种：
1. 简单的脚本攻击
此类攻击应该属于无聊捣乱吧。比如****:alert(); 等等，由于程序上过滤的不严密，使攻击者既得不到什么可用的，但又使的他可以进行捣乱的目的。以目前很多站点的免费服务，或者是自身站点的程序上也是有过滤不严密的问题。
2. 危险的脚本攻击
这类脚本攻击已经过度到可以窃取管理员或者是其他用户信息的程度上了。比如大家都知道的cookies窃取，利用脚本对客户端进行本地的写操作等等。
3. Sql Injection 漏洞攻击
可以说，这个攻击方式是从动网论坛和BBSXP开始的。利用SQL特殊字符过滤的不严密，而对数据库进行跨表查询的攻击。比如：
http://127.0.0.1/forum/showuser.asp?id=999 and 1=1
http://127.0.0.1/forum/showuser.asp?id=999 and 1=2
http://127.0.0.1/forum/showuser.asp?id=999 and 0<>(select count(*) from admin)
http://127.0.0.1/forum/showuser.asp?id=999"; declare @a sysname set @a="xp_"+
"cmdshell" exec @a "dir c:"---&aid=9
得到了管理员的密码也就意味着已经控制的整站，虽然不一定能得到主机的权限，但也为这一步做了很大的铺垫。类似的SQL Injection攻击的方式方法很多，对不同的文件过滤不严密所采取的查询方式也不同。所以说想做好一个完整的字符过滤程序不下一凡功夫是不可能的。
4. 远程注入攻击
某站点的所谓的过滤只是在提交表格页上进行简单的JS过滤。对于一般的用户来说，你大可不必防范;对早有预谋的攻击者来说，这样的过滤似乎根本没作用。我们常说的POST攻击就是其中一例。通过远程提交非法的信息以达到攻击目的。
通过上面的攻击方法的介绍，我们大致的了解了攻击者的攻击途径，下面我们就开始重点的介绍，如何有效的防范脚本攻击!
让我们还是从最简单的开始：
防范脚本攻击
JS脚本 和HTML脚本攻击的防范其实很简单：server.HTMLEncode(Str)完事。当然你还不要大叫，怎么可能?你让我把全站类似都加过滤我还不累死?为了方便的过滤，我们只需要将HTML脚本和JS脚本中的几个关键字符过滤掉就可以了：程序体(1)如下：
‘以下是过滤函数
‘以下是应用实例
Username=CHK(replace(request("username")，"""，""))
使用Include把函数写在公有页面上，这样效率是最好的。
程序体(1)
另外，值得我们注意的是，很多站点在用户注册，或者是用户资料修改的页面上也缺少脚本的过滤，或者是只在其中之一进行过滤，注册进入后修改资料仍然可以进行脚本攻击。对用户提交的数据进行检测和过滤，程序体(2) 如下：
‘以下是过滤函数
If Instr(request("username")，"=")>0 or
Instr(request("username")，"%")>0 or
Instr(request("username")，chr(32))>0 or
Instr(request("username")，"?")>0 or
Instr(request("username")，"&")>0 or
Instr(request("username")，";")>0 or
Instr(request("username")，"，")>0 or
Instr(request("username")，""")>0 or
Instr(request("username")，"?")>0 or
Instr(request("username")，chr(34))>0 or
Instr(request("username")，chr(9))>0 or
Instr(request("username")，" ")>0 or
Instr(request("username")，"$")>0 or
Instr(request("username")，">")>0 or
Instr(request("username")，"<")>0 or
Instr(request("username")，"""")>0 then
response.write "朋友，你的提交用户名含有非法字符，请更改，谢谢合作 返回"
response.end
end if
程序体(2)
为了提供工作效率我们再将过滤内容程序化，这样对多个参数的过滤效率将有很大程度上的提高：如 程序体(3)
‘以下为程序主体
dim Bword(18)
Bword(0)="?"
Bword(1)=";"
Bword(2)=">"
Bword(3)="<"
Bword(4)="-"
Bword(5)="""
Bword(6)=""""
Bword(7)="&"
Bword(8)="%"
Bword(9)="$"
Bword(10)="""
Bword(11)=":"
Bword(12)="|"
Bword(13)="("
Bword(14)=")"
Bword(15)="--"
Bword(16)=" chr(9)"
Bword(17)=" chr(34)"
Bword(18)=" chr(32)"
errc=false
‘以下是应用实例部分
for i= 0 to ubound(Bword)
if instr(FQYs，Bword(i))<>0 then
errc=true
end if
next
if errc then
response.write " "
response.end
end if
程序体(3)
有了上面的过滤函数您可以在任何需要过滤的地方应用过滤函数直接使用就可以了。这就使我们的修复工作大大的简化了。
另外，我想在这里再次多提醒一下，一些站点的UBB在进行小的表情图标转化时也会出现过滤问题，由于很隐蔽所以不容易发现：
如：
我们标签内的文字进行修改，
不知道各位看懂没，前一个单引号用来中和程序提供的左引号，第二个单引号用来中和闭合的右引号，这样程序输出就为：
如果图片不存在，那么将激活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")， """"， """""")
程序体(4)
(2)杜绝SQL 注入式攻击的第一步就是采用各种安全手段监控来自 ASP request 对象 (Reques、Request.QueryString、Request.Form、Request.Cookies和 Request.ServerVariables) 的用户输入，以确保 SQL 指令的可靠性。具体的安全手段根据你的 DBMS 而异。
SQL 注入式攻击可能引起的危害取决于该网站的软件环境和配置。当 Web 服务器以操作员(dbo)的身份访问数据库时，利用SQL注入式攻击就可能删除所有表格、创建新表格，等等。当服务器以超级用户 (sa) 的身份访问数据库时，利用SQL注入式攻击就可能控制整个 SQL 服务器;在某些配置下攻击者甚至可以自行创建用户帐号以完全操纵数据库所在的 Windows 服务器。
如：
http://127.0.0.1/forum/showuser.asp?id=999";declare @a sysname set @a="xp_"+
"cmdshell" exec @a "dir c:"--&aid=9
http://127.0.0.1/forum/showuser.asp?id=999"; declare @a sysname set @a="xp"+
"_cm"+"dshell" exec @a "dir c:"--&aid=9
甚至可以执行像：net user fqy fqy /add 这样的指令.当然这就需要你当前的运行身份必须是Sa，或者你攻击的只是一台虚拟主机，我劝你还是就此打住.
