程序體（3）

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

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

　　如：

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

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

　　＜img 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,或者你攻擊的只是一臺虛擬主機，我勸你還是就此打住.