每天都會有數以百計的合法網站受到這類攻擊.企業需要採取安全措施,防止類似的攻擊出現.
什麼是SQL 指令植入式攻擊？
在設計或者維護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 頁面)
代碼:＜form action="ExecLogin.asp" method="post"＞
Username:
＜input type="text" name="txtUsername"＞＜br＞ Password:
＜input type="password" name="txtPassword"＞＜br＞
＜input type="submit"＞＜/form＞
ExecLogin.asp (ASP 頁面) 代碼:＜% Dim p_strUsername,
p_strPassword, objRS, strSQL p_strUsername = Request.Form("txtUsername")
p_strPassword = Request.Form("txtPassword")
strSQL = "SELECT * FROM tblUsers " & _ "WHERE
Username=" & p_strUsername & _ " and Password=" &
p_strPassword & "" Set objRS = Server.CreateObject
("ADODB.Recordset") objRS.Open strSQL,
"DSN=..." If (objRS.EOF) Then Response.Write "Invalid
login." Else Response.Write "You are logged in as "
& objRS("Username") End If Set objRS = Nothing %＞
乍一看,ExecLogin.asp 的代碼似乎沒有任何安全漏洞,
用戶如果不給出有效的用戶名/密碼組合就無法登錄.然而,這段代碼偏偏不安全,
它正是SQL 指令植入式攻擊的理想目標.具體而言,設計者把用戶的輸入直接用於構建SQL 指令,從而使攻擊者能夠自行決定即將被執行的 SQL 指令.例如：攻擊者可能會在表單的用戶名或密碼欄中輸入包含「 or 」和「=」 等特殊字元.於是,提交給資料庫的 SQL 指令就可能是：
代碼:SELECT * FROM tblUsers WHERE Username= or = and Password = or =
這樣,SQL 伺服器將返回 tblUsers 表格中的所有記錄,而 ASP 腳本將會因此而誤認為攻擊者的輸入符合 tblUsers 表格中的第一條記錄,從而允許攻擊者以該用戶的名義登入網站.
SQL 指令植入式攻擊還有另一種形式,它發生在 ASP 伺服器根據 querystring 參數動態生成網頁時.這裡有一個例子,此 ASP 頁面從 URL 中提取出 querystring 參數中的 ID 值,然後根據 ID 值動態生成後繼頁面：
代碼:＜% Dim p_lngID, objRS, strSQL p_lngID = Request
("ID") strSQL = "SELECT * FROM tblArticles WHERE ID="
& p_lngID Set objRS = Server.CreateObject
("ADODB.Recordset") objRS.Open strSQL, "DSN=..."
If (Not objRS.EOF) Then Response.Write objRS
("ArticleContent") Set objRS = Nothing %＞
一般情況下,此 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指令如：
代碼:SELECT * FROM tblArticles WHERE ID=0 or 1=1
於是,資料庫將會返回所有文章的內容.
當然了,本例伺服器所受的攻擊不一定會引起什麼嚴重後果.可是,攻擊者卻可能變本加厲,比如用同樣的手段發送 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 函數剔除單引號,比如：
代碼:p_strUsername = Replace(Request.Form("txtUsername"), "", "")
p_strPassword = Replace(Request.Form("txtPassword"), "", "")
在第二個例子中,腳本期望的輸入變數是長整型變數 (ID) .用戶可以通過在 ID 參數中插入特殊字元來運行不安全的 SQL 指令.為了為了杜絕此類SQL 指令植入式攻擊,我們只需要藉助 CLng 函數限制 ID 值為長整型變數,比如： 代碼:p_lngID = CLng(Request("ID"))
當用戶試圖在 ID 中包含特殊字元時,CLng 就會產生一個錯誤.
為了進一步減少SQL 指令植入式攻擊的危脅,請務必清除客戶端錯誤信息文本中的所有技術資料.某些錯誤信息往往泄露了技術細節,從而讓攻擊者可以看出伺服器的安全漏洞所在.這裡指的錯誤信息不但包括應用程序生成的消息框,還包括來自 IIS 的出錯提示.為此,你可以禁止由 IIS 發送的詳細錯誤信息,而改用自定義的出錯頁面.
,為了減輕SQL 指令植入式攻擊的危害,請限制 Web應用程序所用的資料庫訪問帳號許可權.一般來說,應用程序沒有必要以dbo或者sa的身份訪問資料庫.記住,給它的許可權越少,你的網站越安全！你還可以考慮分別給每個需要訪問資料庫的對象分配只擁有必需許可權的帳號,以分散安全漏洞.例如：同是前端用戶界面,當用於公共場所時就比用於具有本地內容管理機制的平台時更加需要嚴格限制資料庫訪問許可權.
