1. 簡單的腳本攻擊

　　此類攻擊應該屬于無聊搗亂吧。比如****:alert(); ＜/table＞等等，由于程序上過濾的不嚴密，使攻擊者既得不到什么可用的，但又使的他可以進行搗亂的目的。以目前很多站點的免費服務，或者是自身站點的程序上也是有過濾不嚴密的問題。

　　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攻擊就是其中一例。通過遠程提交非法的信息以達到攻擊目的。

　　通過上面的攻擊方法的介紹，我們大致的了解了攻擊者的攻擊途徑，下面我們就開始重點的介紹，如何有效的防范腳本攻擊！

　　讓我們還是從最簡單的開始：

　　l 防范腳本攻擊

　　JS腳本 和HTML腳本攻擊的防范其實很簡單：server.HTMLEncode（Str）完事。當然你還不要大叫，怎么可能？你讓我把全站類似＜%=uid%＞都加過濾我還不累死？為了方便的過濾，我們只需要將HTML腳本和JS腳本中的幾個關鍵字符過濾掉就可以了：程序體（1）如下：

　　‘以下是過濾函數

　�。�%

　　function CHK(fqyString)

　　fqyString = replace(fqyString, "＞", "＞")

　　fqyString = replace(fqyString, "＜", "＜")

　　fqyString = replace(fqyString, "&#", "&")

　　fqyString = Replace(fqyString, CHR(32), " ")

　　fqyString = Replace(fqyString, CHR(9), " ")

　　fqyString = Replace(fqyString, CHR(34), """)

　　fqyString = Replace(fqyString, CHR(39), "'")

　　fqyString = Replace(fqyString, CHR(13), "")

　　fqyString = Replace(fqyString, CHR(10) & CHR(10), "＜/P＞＜P＞ ")

　　fqyString = Replace(fqyString, CHR(10), "＜BR＞ ")

　　CHK = fqyString

　　end function

　　%＞

　　‘以下是應用實例

　　＜%=CHK(Username)%＞

　　Username=CHK(replace(request(“username”),”’”,””))

　　使用Include把函數寫在公有頁面上，這樣效率是最好的。

　　另外，值得我們注意的是，很多站點在用戶注冊，或者是用戶資料修改的頁面上也缺少腳本的過濾，或者是只在其中之一進行過濾，注冊進入后修改資料仍然可以進行腳本攻擊。對用戶提交的數據進行檢測和過濾，程序體（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"),"?K")＞0 or
　　Instr(request("username"),"$")＞0 or
　　Instr(request("username"),"＞")＞0 or
　　Instr(request("username"),"＜")＞0 or
　　Instr(request("username"),"""")＞0 then
　　response.write "朋友，你的提交用戶名含有非法字符，請更改，謝謝合作 ＜a href='****:window.history.go(-1);'＞返回＜/a＞"
　　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 "＜script language=""****""＞"
　　response.write "parent.alert('很抱歉!您的操作違法了);"
　　response.write "history,back();"
　　response.write "＜/script＞"
　　response.end
　　end if

　　有了上面的過濾函數您可以在任何需要過濾的地方應用過濾函數直接使用就可以了。這就使我們的修復工作大大的簡化了。

　　另外，我想在這里再次多提醒一下，一些站點的UBB在進行小的表情圖標轉化時也會出現過濾問題，由于很隱蔽所以不容易發現：

　　如：

　　我們標簽內的文字進行修改，

　　不知道各位看懂沒，前一個單引號用來中和程序提供的左引號，第二個單引號用來中和閉合的右引號，這樣程序輸出就為：

　�。糹mg src=http://edu.chinaz.com/Get/Security/Defence/’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注入的程序：如

　　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 ""
　　response.end
　　end if

　　我要做點聲明的是：以上的程序只是對GET方式提交的數據進行的過濾，千萬不要盲目套用。

　　像其他一些來自 ASP request 對象 (Reques、Request.QueryString、Request.Form、Request.Cookies和 Request.ServerVariables) 的用戶輸入的攻擊方法的方法，大致都集中在腳本期望的輸入變量是數字變量 (ID) 上，當然我們不能只看數字變量，比如：

　　http://127.0.0.1/systembbs/showtopic.asp?tid=99&name=abc' and left(userpasswor d,1)='a

　　http://127.0.0.1/systembbs/addtopic.asp?tid=99&name=abc' and userpasswor d=’or’’=’

　　另外,如何單一的防止類似這樣的注入錯誤?

　　http://127.0.0.1/systembbs/addtopic.asp?tid=99’ ;delete forum_forum;--&page=33 防范程序: 程序體(6)

　　……addtopic.asp?action=add……
　　……addtopic.asp?action=delect……
　　Action1=trim(Request.QueryString())
　　if left(action1,7)<>"action=" then '限定querystring必須為 action=
　　error(err01)'錯誤處理
　　else
　　action=Request.querystring("action")'取得querystring的值
　　end if
　　select case action'對querystring進行處理
　　case "add"
　　.....
　　case "delete"
　　......
　　case else '如果querystring沒有這個值則進行錯誤處理
　　error(err02)
　　end select

　　程序體(6)

　　出現這樣的攻擊，使我們的站長們不得不又再次頭痛，這里我可以給出大家一個解決最好辦法，一般的來說，用戶名長度字符數不會超過15個字符，大都為14字符。那么我們從長度出發，來進行過濾：如程序體（7）

　　Name=replace(name,”’”,””)
　　If len(name)>16 then
　　Response.write “ 你要做什么?”
　　Response.end
　　End if

　　程序體（7）

　　為什么我們這里以及過濾了單引號，怎么還要再次取一個長度限制呢？不多說了，看看4ngel的文章先<<饒過'限制繼續射入>> .別問我怎么轉數字格式，我不會,嘿嘿…^_^!

　　還繼續回到我們的主題,” 腳本期望的輸入變量是數字變量 (ID)”.怎樣進行注入防范,天吶,方法太多了，最直接的就是判斷是否是數字整型,還有一些比較個性的驗證辦法,我們一一介紹一下 如:程序體(8)

　　一,判斷數字是否是整型

　　p_lngID = CLng(Request("ID"))

　　二 取字長 這一點我相信一般的數據長度不會大于8位所以:

　　If len(ID)>8 then
　　response.write “bedpost”
　　response end
　　end if

　　sql = "SELECT NAME FROM Category where ID="&ID
　　set temp=conn.Execute(SQL)
　　if temp.bof or temp.eof then
　　response.Redirect("index.asp")
　　else
　　cat_name=temp("name")
　　end if
　　set temp=nothing

　　‘上面的是數據ID 的檢測,下面則是正式的查詢

　　sql = "SELECT ID T_ID, NAME FROM Category where ID="&ID&" ORDER BY xh asc"
　　rs.open sql,conn,1,1

　　四,我自己常用的數據過濾腳本,專利,呵~

　　id=replace(id,”’”,””)
　　If len( request(“id”))>8 then ‘ 為什么取長度上面程序中已經說明
　　response.write ""
　　response.end
　　else

　　If request(“id”)<>”” then ‘取不為空則是為了防止一些程序頁中會出現空值情況，如果不在這里做判斷,程序會校驗出錯.

　　If IsNumeric(request("id"))=False then ' 風清揚修改 ID數據監控程式
　　response.write ""
　　response.end
　　end if
　　end if
　　end if

　　程序體(8)

　　由于我個人的編程習慣,我喜歡將所有的數據檢驗程序全部保留到整站的公用程序中,比如:conn.asp啦,只需要寫一次就可以修復全站的問題.

　　說到這里,我提一點關于攻擊的問題，就是跑用戶密碼或者是用戶名,一般常用的就是

　　….../show.asp?id=1 and 0＜＞(select count(*) from admin where id=3 and left(username,1)=’a’)

　　這樣去一個一個嘗試,當然我們不能在這里提什么Perl程序去跑密碼,程序是別人寫,要自己知道原理.這里我只是想給個比較方便的辦法就是取ASC碼范圍.這個要比單獨跑要快很多.不論是是字母,數字,漢字,特殊字符,他們總會有對應的ASC碼,用以下辦法:

　　….../show.asp?id=1 and 0＜＞(select count(*) from admin where id=3 and asc(right(left(usernamee,3),1)) between 1 and 10000)

　　剩下的就隨你了，一般的從97到122就可以啦,字母嘛,很快D.呵呵，有人想用mid 函數當然也是不錯 asc(mid(username,2,1)) between 1 and 10000 也成.

　　如何更加有效的防止SQL注入攻擊?我們將在下面的文章中具體提到!

　　l 防范遠程注入攻擊

　　這類攻擊在以前應該是比較常見的攻擊方式,比如POST攻擊,攻擊者可以隨便的改變要提交的數據值已達到攻擊目的.又如:COOKIES 的偽造,這一點更值得引起程序編寫者或站長的注意，不要使用COOKIES來做為用戶驗證的方式,否則你和把鑰匙留給賊是同一個道理.

　　比如:

　　If trim(Request. cookies ("uname"))="fqy" and Request.cookies("upwd") =”fqy#e3i5.com” then
　　……..more………
　　End if

　　我想各位站長或者是喜好寫程序的朋友千萬別出這類錯誤,真的是不可饒恕.偽造COOKIES 都多少年了，你還用這樣的就不能怪別人跑你的密碼.涉及到用戶密碼或者是用戶登陸時,你最好使用session 它才是最安全的.如果要使用COOKIES就在你的COOKIES上多加一個信息,SessionID,它的隨機值是64位的,要猜解它,不可能.例:

　　if not (rs.BOF or rs.eof) then
　　login="true"
　　Session("username"&sessionID) = Username
　　Session("password"& sessionID) = Password
　　‘Response.cookies(“username”)= Username
　　‘Response.cookies(“Password”)= Password

　　下面我們來談談如何防范遠程注入攻擊,一般的攻擊都是將單表提交文件拖到本地,將Form ACTION=”chk.asp” 指向你服務器中處理數據的文件即可.如果你全部的數據過濾都在單表頁上，那么恭喜你，你將已經被腳本攻擊了.

　　怎么才能制止這樣的遠程攻擊?好辦,請看代碼如下: 程序體(9)

　�。�%
　　server_v1=Cstr(Request.ServerVariables("HTTP_REFERER"))
　　server_v2=Cstr(Request.ServerVariables("SERVER_NAME"))
　　if mid(server_v1,8,len(server_v2))＜＞server_v2 then
　　response.write "＜br＞＜br＞＜center>"
　　response.write " "
　　response.write "你提交的路徑有誤，禁止從站點外部提交數據請不要亂該參數！"
　　response.write "

"
　　response.end
　　end if
　　%>

　　‘個人感覺上面的代碼過濾不是很好，有一些外部提交竟然還能堂堂正正的進來,于是再寫一個.

　　‘這個是過濾效果很好,建議使用.

　　if instr(request.servervariables("http_referer"),"http://"&request.servervariables("host") )<1 then response.write "處理 URL 時服務器上出錯。
如果您是在用任何手段攻擊服務器，那你應該慶幸，你的所有操作已經被服務器記錄，我們會第一時間通知公安局與國家安全部門來調查你的IP. "
　　response.end
　　end if

　　本以為這樣就萬事大吉了，在表格頁上加一些限制,比如maxlength啦,等等..但天公就是那么不作美,你越怕什么他越來什么.你別忘了,攻擊者可以突破sql注入攻擊時輸入框長度的限制.寫一個SOCKET程序改變HTTP_REFERER？我不會。網上發表了這樣一篇文章：

　　------------len.reg-----------------
　　Windows Registry Editor Version 5.00
　　[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\MenuExt\擴展(&E)]
　　@="C:\Documents and Settings\Administrator\桌面\len.htm"
　　"contexts"=dword:00000004
　　-----------end----------------------
　　-----------len.htm------------------
　　
　　----------end-----------------------

　　用法:先把len.reg導入注冊表(注意文件路徑)

　　然后把len.htm拷到注冊表中指定的地方.

　　打開網頁,光標放在要改變長度的輸入框上點右鍵,看多了一個叫擴展的選項了吧

　　單擊搞定! 后記:同樣的也就可以對付那些限制輸入內容的腳本了.

　　怎么辦？我們的限制被饒過了，所有的努力都白費了？不，舉起你de鍵盤，說不。讓我們繼續回到腳本字符的過濾吧，他們所進行的注入無非就是進行腳本攻擊。我們把所有的精力全都用到ACTION以后的頁面吧，在chk.asp頁中，我們將非法的字符全部過濾掉，結果如何？我們只在前面虛晃一槍，叫他們去改注冊表吧，當他們改完才會發現，他們所做的都是那么的徒勞。

　　ASP木馬

　　已經講到這里了，再提醒各位論壇站長一句，小心你們的文件上傳：為什么論壇程序被攻破后主機也隨之被攻擊者占據。原因就在……對！ASP木馬！一個絕對可惡的東西。病毒么？非也.把個文件隨便放到你論壇的程序中，您老找去吧。不吐血才怪哦。如何才能防止ASP木馬被上傳到服務器呢？方法很簡單，如果你的論壇支持文件上傳，請設定好你要上傳的文件格式，我不贊成使用可更改的文件格式，直接從程序上鎖定，只有圖象文件格式，和壓縮文件就完全可以，多給自己留點方便也就多給攻擊者留點方便。怎么判斷格式，我這里收集了一個，也改出了一個，大家可以看一下：

　　程序體（10）

　　'判斷文件類型是否合格
　　Private Function CheckFileExt (fileEXT)
　　dim Forumupload
　　Forumupload="gif,jpg,bmp,jpeg"
　　Forumupload=split(Forumupload,",")
　　for i=0 to ubound(Forumupload)
　　if lcase(fileEXT)=lcase(trim(Forumupload(i))) then
　　CheckFileExt=true
　　exit Function
　　else
　　CheckFileExt=false
　　end if
　　next
　　End Function
　　‘驗證文件內容的合法性
　　set MyFile = server.CreateObject ("Scripting.FileSystemObject")
　　set MyText = MyFile.OpenTextFile (sFile, 1) ' 讀取文本文件
　　sTextAll = lcase(MyText.ReadAll): MyText.close
　　'判斷用戶文件中的危險操作
　　sStr ="8　.getfolder　.createfolder　.deletefolder　.createdirectory　
　　.deletedirectory"
　　sStr = sStr & "　.saveas　wscript.shell　script.encode"
　　sNoString = split(sStr,"　")
　　for i = 1 to sNoString(0)
　　if instr(sTextAll, sNoString(i)) ＜＞ 0 then
　　sFile = Upl.Path & sFileSave: fs.DeleteFile sFile
　　Response.write "＜center＞＜br＞＜big＞"& sFileSave &"文件中含有與操作目錄等有關的命令"&_
　　"＜br＞＜font color=red＞"& mid(sNoString(i),2) &"＜/font＞，為了安全原因，＜b＞不能上傳。＜b＞"&_"＜/big＞＜/center＞＜/html＞"
　　Response.end
　　end if
　　next

　　程序體（10）

　　把他們加到你的上傳程序里做一次驗證，那么你的上傳程序安全性將會大大提高.

　　什么？你還不放心？拿出殺手锏，請你的虛擬主機服務商來幫忙吧。登陸到服務器，將PROG ID 中的"shell.application"項和"shell.application.1"項改名或刪除。再將”WSCRIPT.SHELL”項和”WSCRIPT.SHELL.1”這兩項都要改名或刪除。呵呵，我可以大膽的說，國內可能近半以上的虛擬主機都沒改過。只能慶幸你們的用戶很合作，否則……我刪，我刪，我刪刪刪……

　　小結

　　如何更好的達到防范SQL Injection的攻擊？這里我個人給推薦幾個辦法，第一，免費程序不要真的就免費用，既然你可以共享原碼，那么攻擊者一樣可以分析代碼。如果有能力的站長最好還是更改一下數據庫表名，字段名，只修改關鍵的admin, username, password就可以了，比如forum_upasswd 這樣的字段名誰能猜到？如果你猜到了，最好趕快去買彩票吧，特等獎不是你還會有誰呢？另外，一般站點的關鍵就在于管理員的密碼，很好的保護好你的管理員密碼那是至關重要的，至少10位的數字字母組合。另外加上現在大多數站點程序都會使用MD5來加密用戶密碼，加上你密碼的強壯性，那樣你站點的安全性就大大的提高了。即使出現了SQL Injection漏洞，攻擊者也不可能馬上拿下你的站點。