脚本攻击防范策略完全篇

程序体（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 "<script language=""****"">" 

response.write "parent.alert('很抱歉!您的操作违法了);" 

response.write "history，back();" 

response.write "</script>" 

response.end 

end if 

程序体（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")， "''"， "''''") 

程序体（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，或者你攻击的只是一台虚拟主机，我劝你还是就此打住. 

对于一些整机使用的站点来说防止通过80端口攻击而直接拿到整机管理权限，这一点就变得至关重要了。对xp_cmdshell 的过滤就成为首要，很多站点的程序都是用GET或者是GET与POST混合来提交数据的，对于此，我们给出一种防止GET进行SQL注入的程序：如程序体（5） 

fqys=request.servervariables("query_string") 

dim nothis(18) 

nothis(0)="net user" 

nothis(1)="xp_cmdshell" 

nothis(2)="/add" 

nothis(3)="exec%20master.dbo.xp_cmdshell" 

nothis(4)="net localgroup administrators" 

nothis(5)="select" 

nothis(6)="count" 

nothis(7)="asc" 

nothis(8)="char" 

nothis(9)="mid" 

nothis(10)="'" 

nothis(11)=":" 

nothis(12)="""" 

nothis(13)="insert" 

nothis(14)="delete" 

nothis(15)="drop" 

nothis(16)="truncate" 

nothis(17)="from" 

nothis(18)="%" 

errc=false 

for i= 0 to ubound(nothis) 

if instr(FQYs，nothis(i))<>0 then 

errc=true 

end if 

next 

if errc then 

response.write "<script language=""****"">" 

response.write "parent.alert('很抱歉!你正在试图攻击本服务器或者想取得本服务器最高管理权!将直接转向首页..');" 

response.write "self.location.href='default.asp';" 

response.write "</script>" 

response.end 

end if 

上一页  [1] [2] [3] [4] 下一页