Tip/Trick: Guard Against SQL Injection Attacks 【原文發表日期】 Saturday, September 30, 2006 9:11 AM SQL注入攻擊是非常令人討厭的安全漏洞,是所有的web開發人員,不管是什么平臺,技術,還是數據層,需要確信他們理解和防止的東西。不幸的是,開發人
Tip/Trick: Guard Against SQL Injection Attacks
【原文發表日期】 Saturday, September 30, 2006 9:11 AM
SQL注入攻擊是非常令人討厭的安全漏洞,是所有的web開發人員,不管是什么平臺,技術,還是數據層,需要確信他們理解和防止的東西。不幸的是,開發人員往往不集中花點時間在這上面,以至他們的應用,更糟糕的是,他們的客戶極其容易受到攻擊。
Michael Sutton 最近發表了一篇非常發人深省的帖子,講述在公共網上這問題是多么地普遍。他用Google的Search API建了一個C#的客戶端程序,尋找那些易受SQL 注入攻擊的網站。其步驟很簡單:
對通過Google搜尋找到的1000個網站的隨機取樣測試,他檢測到其中的11.3%有易受SQL注入攻擊的可能。這非常,非常地可怕。這意味著黑客可以遠程利用那些應用里的數據,獲取任何沒有hashed或加密的密碼或信用卡數據,甚至有以管理員身份登陸進這些應用的可能。這不僅對開發網站的開發人員來說很糟糕,而且對使用網站的消費者或用戶來說更糟糕,因為他們給網站提供了數據,想著網站是安全的呢。
那么SQL注入攻擊到底是什么玩意?
有幾種情形使得SQL注入攻擊成為可能。最常見的原因是,你動態地構造了SQL語句,卻沒有使用正確地加了碼(encoded)的參數。譬如,考慮這個SQL查詢的編碼,其目的是根據由查詢字符串提供的社會保險號碼(social security number)來查詢作者(Authors):
Dim SSN as String
Dim SqlQuery as StringSSN = 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 ' SQL Query executed against the database
http://mysite.com/listauthordetails.aspx?SSN=172-32-9999';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
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)產品組發表了許多非常棒的安全指導方針方面的文檔,你應該留出些時間來閱讀一下:
此外,還有這些其他的PAG How-To文章對進一步了解如何保護你免受注入攻擊大有用處:
你還可以在我寫的這篇關于安全的博客帖子以及我的ASP.NET 技巧和訣竅頁上找到關于ASP.NET安全方面的有用的信息。
更新: Bertrand給我指出了他2年前寫的這篇關于SQL注入攻擊的非常棒的帖子,非常值得一讀。
希望本文對你有所幫助,
Scott
ASP.NET, Security, Tips and Tricks
(思歸譯)聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com