SQL注入攻擊與防禦

什麼是SQL注入攻擊

SQL注入攻擊是黑客對資料庫進行攻擊的常用手段之一。隨著B/S模式應用開發的發展，使用這種模式編寫應用程序的程序員也越來越多。但是由於程序員的水平及經驗也參差不齊，相當大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段資料庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數據，這就是所謂的SQL Injection，即SQL注入。

SQL注入攻擊屬於資料庫安全攻擊手段之一，可以通過資料庫安全防護技術實現有效防護，資料庫安全防護技術包括：資料庫漏掃、資料庫加密、資料庫防火牆、數據脫敏、資料庫安全審計系統。

SQL注入攻擊會導致的資料庫安全風險包括：刷庫、拖庫、撞庫。

常見的SQL注入式攻擊過程類

某個ASP.NET Web應用有一個登錄頁面，這個登錄頁面控制著用戶是否有權訪問應用，它要求用戶輸入一個名稱和密碼。

登錄頁面中輸入的內容將直接用來構造動態的SQL命令，或者直接用作存儲過程的參數。下面是ASP.NET應用構造查詢的一個例子：

System.Text.StringBuilder query = new System.Text.StringBuilder(

「SELECT * from Users WHERE login = 『」)

.Append(txtLogin.Text).Append(「『 AND password='」)

.Append(txtPassword.Text).Append(「『」);

攻擊者在用戶名字和密碼輸入框中輸入」『或』1』=』1″之類的內容。

用戶輸入的內容提交給伺服器之後，伺服器運行上面的ASP.NET代碼構造出查詢用戶的SQL命令，但由於攻擊者輸入的內容非常特殊，所以最後得到的SQL命令變成：SELECT * from Users WHERE login = 」 or 『1』=』1′ AND password = 」 or 『1』=』1』。

伺服器執行查詢或存儲過程，將用戶輸入的身份信息和伺服器中保存的身份信息進行對比。

由於SQL命令實際上已被注入式攻擊修改，已經不能真正驗證用戶身份，所以系統會錯誤地授權給攻擊者。

如果攻擊者知道應用會將表單中輸入的內容直接用於驗證身份的查詢，他就會嘗試輸入某些特殊的SQL字元串篡改查詢改變其原來的功能，欺騙系統授予訪問許可權。

系統環境不同，攻擊者可能造成的損害也不同，這主要由應用訪問資料庫的安全許可權決定。如果用戶的帳戶具有管理員或其他比較高級的許可權，攻擊者就可能對資料庫的表執行各種他想要做的操作，包括添加、刪除或更新數據，甚至可能直接刪除表

如何防範

SQL注入攻擊是需要擔心的事情，不管用什麼web編程技術，再說所有的web框架都需要擔心這個的。需要遵循幾條非常基本的規則：

1）在構造動態SQL語句時，一定要使用類安全（type-safe）的參數加碼機制。大多數的數據API，包括ADO和ADO. NET，有這樣的支持，允許指定所提供的參數的確切類型（譬如，字元串，整數，日期等），可以保證這些參數被恰當地escaped/encoded了，來避免黑客利用它們。一定要從始到終地使用這些特性。

例如，在ADO. NET里對動態SQL，可以象下面這樣重寫上述的語句，使之安全：

Dim SSN as String = Request.QueryString(「SSN」)

Dim cmd As new SqlCommand(「SELECT au_lname,au_fname FROM authors WHERE au_id = @au_id」)

Dim param = new SqlParameter(「au_id」,SqlDbType.VarChar)

param.Value = SSN

cmd.Parameters.Add(param)

這將防止有人試圖偷偷注入另外的SQL表達式（因為ADO. NET知道對au_id的字元串值進行加碼），以及避免其他數據問題（譬如不正確地轉換數值類型等）。注意，VS 2005內置的TableAdapter/DataSet設計器自動使用這個機制，ASP. NET 2.0數據源控制項也是如此。

一個常見的錯誤知覺（misperception）是，假如使用了存儲過程或ORM，就完全不受SQL注入攻擊之害了。這是不正確的，還是需要謹慎確定在給存儲過程傳遞數據時，或在用ORM來定製一個查詢時，你的做法是安全的。

2）在部署應用前，始終要做安全審評（security review）。建立一個正式的安全過程（formal security process），在每次更新時，對所有的編碼做審評。後面一點特別重要。曾經多次聽說開發隊伍在正式上線（going live）前會做很詳細的安全審評，然後在幾周或幾個月之後他們做一些很小的更新時，他們會跳過安全審評這關，說，「就是一個小小的更新，我們以後再做編碼審評好了」。請始終堅持做安全審評。

3） 千萬別把敏感性數據在資料庫里以明文存放。個人的意見是，密碼應該總是在單向（one-way)hashed過後再存放，不喜歡將它們在加密後存放。在默認設置下，ASP. NET 2.0 Membership API 自動為你這麼做，還同時實現了安全的SALT 隨機化行為（SALT randomization behavior）。如果決定建立自己的成員資料庫，建議查看一下我們在這裡發表的我們自己的Membership provider的源碼。同時也確定對你的資料庫里的信用卡和其他的私有數據進行了加密。這樣即使你的資料庫被人入侵（compromised）了的話，起碼你的客戶的私有數據不會被人利用。

4）確認編寫了自動化的單元測試，來特別校驗你的數據訪問層和應用程序不受SQL注入攻擊。這麼做是非常重要的，有助於捕捉住（catch）「就是一個小小的更新，所有不會有安全問題」的情形帶來的疏忽，來提供額外的安全層以避免偶然地引進壞的安全缺陷到你的應用里去。

5）鎖定你的資料庫的安全，只給訪問資料庫的web應用功能所需的最低的許可權。如果web應用不需要訪問某些表，那麼確認它沒有訪問這些表的許可權。如果web應用只需要只讀的許可權從你的account payables表來生成報表，那麼確認你禁止它對此表的 insert/update/delete 的許可權。

6）很多新手從網上下載SQL通用防注入系統的程序，在需要防範注入的頁面頭部用 來防止別人進行手動注入測試（。

可是如果通過SQL注入分析器就可輕鬆跳過防注入系統並自動分析其注入點。然後只需要幾分鐘，你的管理員賬號及密碼就會被分析出來。

7）對於注入分析器的防範，筆者通過實驗，發現了一種簡單有效的防範方法。首先我們要知道SQL注入分析器是如何工作的。在操作過程中，發現軟體並不是沖著「admin」管理員賬號去的，而是沖著許可權（如flag=1）去的。這樣一來，無論你的管理員賬號怎麼變都無法逃過檢測。

第三步：既然無法逃過檢測，那我們就做兩個賬號，一個是普通的管理員賬號，一個是防止注入的賬號，為什麼這麼說呢？筆者想，如果找一個許可權最大的賬號製造假象，吸引軟體的檢測，而這個賬號里的內容是大於千字以上的中文字元，就會迫使軟體對這個賬號進行分析的時候進入全負荷狀態甚至資源耗盡而死機。下面我們就來修改資料庫吧。

對錶結構進行修改。將管理員的賬號欄位的數據類型進行修改，文本型改成最大欄位255（其實也夠了，如果還想做得再大點，可以選擇備註型），密碼的欄位也進行相同設置。

對錶進行修改。設置管理員許可權的賬號放在ID1，並輸入大量中文字元（最好大於100個字）。

把真正的管理員密碼放在ID2後的任何一個位置（如放在ID549上）。

由於SQL注入攻擊針對的是應用開發過程中的編程不嚴密，因而對於絕大多數防火牆來說，這種攻擊是「合法」的。問題的解決只有依賴於完善編程。專門針對SQL注入攻擊的工具較少，Wpoison對於用asp，php進行的開發有一定幫助…。

GDCA（數安時代）擁有國內自主簽發信鑒易 TrustAUTH SSL證書以及是國際多家知名品牌：GlobalSign、Symantec、GeoTrust SSL證書指定的國內代理商。為了讓國內更多的網站升級到安全的https加密傳輸協議。近日，GDCA推出多種國際知名SSL證書優惠活動，實現HTTPS加密並展示網站真實身份信息。詳情請資訊GDCA產品官網在線客服https://www.trustauth.cn/。

文章轉載：https://www.trustauth.cn/wiki/15576.html

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！