網頁腳本攻擊防範全攻略(二)程序體（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"),"?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
程序體（3）
有了上面的過濾函數您可以在任何需要過濾的地方應用過濾函數直接使用就可以了。這就使我們的修復工作大大的簡化了。
另外，我想在這裏再次多提醒一下，一些站點的UBB在進行小的表情圖標轉化時也會出現過濾問題，由於很隱蔽所以不容易發現：
如：
我們標籤內的文字進行修改，
不知道各位看懂沒，前一個單引號用來中和程序提供的左引號，第二個單引號用來中和閉合的右引號，這樣程序輸出就爲：
＜img src=’img/0001.gif’ οnerrοr=****: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注入的程序：如