sql注入性攻擊

【原文位址】Tip/Trick: Guard Against SQL Injection Attacks

【原文發表日期】 Saturday, September 30, 2006 9:11 AM

SQL注入攻擊是非常令人讨厭的安全漏洞，是所有的web開發人員，不管是什麼平台，技術，還是資料層，需要确信他們了解和防止的東西。不幸的是，開發人員往往不集中花點時間在這上面，以至他們的應用，更糟糕的是，他們的客戶極其容易受到攻擊。

Michael Sutton 最近發表了一篇非常發人深省的文章，講述在公共網上這問題是多麼地普遍。他用Google的Search API建了一個C#的用戶端程式，尋找那些易受SQL 注入攻擊的網站。其步驟很簡單：

1. 尋找那些帶查詢字元串的網站(例如，查詢那些在URL裡帶有 "id=" 的URL)
2. 給這些确定為動态的網站發送一個請求，改變其中的id=語句，帶一個額外的單引号，來試圖取消其中的SQL語句(例如，如 id=6' )
3. 分析傳回的回複，在其中查找象“SQL” 和“query”這樣的詞，這往往表示應用傳回了詳細的錯誤消息(這本身也是很糟糕的)
4. 檢查錯誤消息是否表示發送到SQL伺服器的參數沒有被正确加碼(encoded)，如果如此，那麼表示可對該網站進行SQL注入攻擊

對通過Google搜尋找到的1000個網站的随機取樣測試，他檢測到其中的11.3%有易受SQL注入攻 擊的可能。這非常，非常地可怕。這意味着黑客可以遠端利用那些應用裡的資料，擷取任何沒有hashed或加密的密碼或信用卡資料，甚至有以管理者身份登陸 進這些應用的可能。這不僅對開發網站的開發人員來說很糟糕，而且對使用網站的消費者或使用者來說更糟糕，因為他們給網站提供了資料，想着網站是安全的呢。

那麼SQL注入攻擊到底是什麼玩意？

有幾種情形使得SQL注入攻擊成為可能。最常見的原因是，你動态地構造了SQL語句，卻沒有使用正确地加了碼(encoded)的參數。譬如，考慮這個SQL查詢的編碼，其目的是根據由查詢字元串提供的社會保險号碼(social security number)來查詢作者(Authors)：

Dim  SSN  as String

Dim  SqlQuery  as String

SSN  =  Request.QueryString( "SSN" )

SqlQuery  =  "SELECT au_lname, au_fname FROM authors WHERE au_id = '"  + SSN +  "'"

如果你有象上面這個片斷一樣的SQL編碼，那麼你的整個資料庫和應用可以遠端地被黑掉。怎麼會呢？在普通情形下，使用者會使用一個社會保險号碼來通路這個網站，編碼是象這樣執行的：

' URL to the page containing the above code

http://mysite.com/listauthordetails.aspx?SSN = 172 - 32 - 9999

' SQL Query executed against the database 

SELECT  au_lname, au_fname FROM authors WHERE au_id  =  '172-32-9999'

這是開發人員預期的做法，通過社會保險号碼來查詢資料庫中作者的資訊。但因為參數值沒有被正确地加碼，黑客可以很容易地修改查詢字元串的值，在要執行的值後面嵌入附加的SQL語句 。譬如，

' URL to the page containing the above code

http://mysite.com/listauthordetails.aspx?SSN = 172 - 32 - 9999';DROP DATABASE pubs --

' SQL Query executed against the database 

SELECT  au_lname, au_fname FROM authors WHERE au_id  = '';DROP DATABASE pubs --

注意到沒有，我可以在SSN查詢字元串值的後面添加“ ';DROP DATABASE pubs -- ”，通過 “;”字元來終止目前的SQL語句，然後添加了我自己的惡意的SQL語句，然後把語句的其他部分用“--”字元串注釋掉。因為我們是手工在編碼裡構造 SQL語句，我們最後把這個字元串傳給了資料庫，資料庫會先對authors表進行查詢，然後把我們的pubs資料庫删除。“砰(bang)”的一聲，數 據庫就沒了！

萬一你認為匿名黑客删除你的資料庫的結果很壞，但不幸的是，實際上，這在SQL注入攻 擊所涉及的情形中算是比較好的。一個黑客可以不單純摧毀資料，而是使用上面這個編碼的弱點，執行一個JOIN語句，來擷取你資料庫裡的所有資料，顯示在頁 面上，允許他們擷取使用者名，密碼，信用卡号碼等等。他們也可以添加 UPDATE/INSERT 語句改變産品的價格，添加新的管理者賬号，真的搞砸你(screw up your life)呢。想象一下，到月底檢查庫存時，發現你庫房裡的實際産品數與你的帳目系統(accounting system)彙報的數目有所不同。。。

那該如何保護你自己？

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 的權限。

如何了解更多的相關知識

微軟Prescriptive Architecture Guidance (PAG)産品組發表了許多非常棒的安全指導方針方面的文檔，你應該留出些時間來閱讀一下：

• ASP.NET 2.0 安全指定方針
• ASP.NET 2.0 安全部署清單
• ASP.NET 2.0 安全實踐概述
• Web應用工程安全索引
• 如何對托管編碼進行安全編碼審評
• ASP.NET 2.0 安全問題清單
• ASP.NET 2.0 安全教育訓練單元(Training Modules)

此外，還有這些其他的PAG How-To文章對進一步了解如何保護你免受注入攻擊大有用處：

• 如何在ASP.NET裡防範表單注入攻擊
• 如何在ASP.NET裡防範SQL注入攻擊

你還可以在我寫的這篇關于安全的部落格文章以及我的ASP.NET 技巧和訣竅頁上找到關于ASP.NET安全方面的有用的資訊。

更新： Bertrand給我指出了他2年前寫的這篇關于SQL注入攻擊的非常棒的文章，非常值得一讀。

希望本文對你有所幫助，