在設計或者維護Web網站時，你也許擔心它們會受到某些卑鄙用戶的惡意攻擊。的確，如今的Web網站開發者們針對其站點所在操作系統平臺或Web 服務器的安全性而展開的討論實在太多了。不錯，IIS 服務器的安全漏洞可能招致惡意攻擊；但你的安全檢查清單不應該僅僅有 IIS 安全性這一條。有些代碼，它們通常是專門為數據驅動(data-driven) 的 Web 網站而設計的，實際上往往同其它IIS漏洞一樣存在嚴重的安全隱患。這些潛伏于代碼中的安全隱患就有可能被稱為“SQL指令植入式攻擊” (SQL injection) 的手段所利用而導致服務器受到攻擊。
SQL指令植入式攻擊技術使得攻擊者能夠利用Web應用程序中某些疏于防范的輸入機會動態生成特殊的 SQL指令語句。舉一個常見的例子：
某Web網站采用表單來收集訪問者的用戶名和密碼以確認他有足夠權限訪問某些保密信息，然后該表單被發送到 Web 服務器進行處理。接下來，服務器端的asp 腳本根據表單提供的信息生成 SQL 指令語句提交到SQL服務器，并通過分析SQL服務器的返回結果來判斷該用戶名/密碼組合是否有效。
為了實現這樣的功能，Web 程序員可能會設計兩個頁面：一個 HTML 頁面 (Login.htm) 用于登錄，另一個ASP 頁面(ExecLogin.asp) 用于驗證用戶權限(即向數據庫查詢用戶名/密碼組合是否存在)。具體代碼可能象這樣：
Login.htm (HTML 頁面)
|
乍一看，ExecLogin.asp 的代碼似乎沒有任何安全漏洞，因為用戶如果不給出有效的用戶名/密碼組合就無法登錄。然而，這段代碼偏偏不安全，而且它正是SQL 指令植入式攻擊的理想目標。具體而言，設計者把用戶的輸入直接用于構建SQL 指令，從而使攻擊者能夠自行決定即將被執行的 SQL 指令。例如：攻擊者可能會在表單的用戶名或密碼欄中輸入包含“ or ”和“=” 等特殊字符。于是，提交給數據庫的 SQL 指令就可能是：
|
這樣，SQL 服務器將返回 tblUsers 表格中的所有記錄，而 ASP 腳本將會因此而誤認為攻擊者的輸入符合 tblUsers 表格中的第一條記錄，從而允許攻擊者以該用戶的名義登入網站。
SQL 指令植入式攻擊還有另一種形式，它發生在 ASP 服務器根據 querystring 參數動態生成網頁時。這里有一個例子，此 ASP 頁面從 URL 中提取出 querystring 參數中的 ID 值，然后根據 ID 值動態生成后繼頁面：
|
在一般情況下，此 ASP 腳本能夠顯示具有特定 ID 值的文章的內容，而 ID 值是由 URL 中的 querystring 參數指定的。例如：當URL為http://www.example.com/Article.asp?ID=1055 時，ASP 就會根據 ID 為1055的文章提供的內容生成頁面。
如同前述登錄頁面的例子一樣，此段代碼也向SQL 指令植入式攻擊敞開了大門。某些惡意用戶可能會把 querystring 中的文章 ID 值偷換為“0 or 1=1”等內容(也就是說，把 URL 換成http://www.example.com/Article.asp?ID=0 or 1=1) 從而誘使 ASP 腳本生成不安全的SQL指令如：
|
于是，數據庫將會返回所有文章的內容。
當然了，本例服務器所受的攻擊不一定會引起什么嚴重后果?？墒牵粽邊s可能變本加厲，比如用同樣的手段發送 DELETE 等SQL指令。這只需要簡單地修改前述 URL 中的querystring 參數就可以了！例如：任何人都可以通過 http://www.example.com/Article.asp?ID=1055; DELETE FROM tblArticles ”之類的URL來訪問Web網站。
SQL指令植入式攻擊的危害
SQL 指令植入式攻擊可能引起的危害取決于該網站的軟件環境和配置。當 Web 服務器以操作員(dbo)的身份訪問數據庫時，利用SQL 指令植入式攻擊就可能刪除所有表格、創建新表格，等等。當服務器以超級用戶 (sa) 的身份訪問數據庫時，利用SQL 指令植入式攻擊就可能控制整個SQL服務器；在某些配置下攻擊者甚至可以自行創建用戶帳號以完全操縱數據庫所在的Windows 服務器。
SQL指令植入式攻擊
杜絕SQL 指令植入式攻擊的第一步就是采用各種安全手段監控來自 ASP request 對象 (Request 、 Request.QueryString 、 Request.Form 、 Request.Cookies 和 Request.ServerVariables) 的用戶輸入，以確保 SQL 指令的可靠性。具體的安全手段根據你的 DBMS 而異，下面給出的都是基于 MS SQL Server的例子。
在前述登錄頁面的例子中，腳本期望得到的兩個輸入變量 (txtUserName 和 txtPassword)均為字符串類型。無論用戶在哪個參數中插入單引號，他都可能讓數據庫執行單引號中的 SQL 指令。為了杜絕此類SQL 指令植入式攻擊，我們可以借助 Replace 函數剔除單引號，比如：
|
在第二個例子中，腳本期望的輸入變量是長整型變量 (ID) 。用戶可以通過在 ID 參數中插入特殊字符來運行不安全的 SQL 指令。為了為了杜絕此類SQL 指令植入式攻擊，我們只需要借助 CLng 函數限制 ID 值為長整型變量，比如： 代碼:p_lngID = CLng(Request("ID"))
當用戶試圖在 ID 中包含特殊字符時，CLng 就會產生一個錯誤。
為了進一步減少SQL 指令植入式攻擊的危脅，請務必清除客戶端錯誤信息文本中的所有技術資料。某些錯誤信息往往泄露了技術細節，從而讓攻擊者可以看出服務器的安全漏洞所在。這里指的錯誤信息不但包括應用程序生成的消息框，還包括來自 IIS 的出錯提示。為此，你可以禁止由 IIS 發送的詳細錯誤信息，而改用自定義的出錯頁面。
最后，為了減輕SQL 指令植入式攻擊的危害，請限制 Web 應用程序所用的數據庫訪問帳號權限。一般來說，應用程序沒有必要以 dbo 或者 sa 的身份訪問數據庫。記住，給它的權限越少，你的網站越安全！你還可以考慮分別給每個需要訪問數據庫的對象分配只擁有必需權限的帳號，以分散安全漏洞。例如：同是前端用戶界面，當用于公共場所時就比用于具有本地內容管理機制的平臺時更加需要嚴格限制數據庫訪問權限。
新聞熱點
疑難解答
