原文地址:http://www.cnblogs.com/rush/archive/2011/12/31/2309203.html
1.1.1 摘要
日前,國內最大的程式猿社群CSDN站點的使用者資料庫被黑客公開公佈,600萬使用者的登入名及password被公開洩露,隨後又有多家站點的使用者password被流傳於網路,連日來引發眾多網民對自己賬號、password等網際網路資訊被盜取的普遍擔憂。
網路安全成為了如今網際網路的焦點,這也恰恰觸動了每一位使用者的神經,因為設計的漏洞導致了不可收拾的惡果,驗證了一句話“出來混的,遲早是要還的”,所以我想通過專題博文介紹一些經常使用的攻擊技術和防範策略。
SQL Injection或許非常多人都知道或者使用過,假設沒有了解或全然沒有聽過也沒有關係,由於接下來我們將介紹SQL Injection。
1.1.2 正文
SQL Injection:就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字串,終於達到欺騙server執行惡意的SQL命令。
詳細來說,它是利用現有應用程式,將(惡意)的SQL命令注入到後臺資料庫引擎執行的能力,它能夠通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的站點上的資料庫,而不是依照設計者意圖去執行SQL語句。
首先讓我們瞭解什麼時候可能發生SQL Injection。
如果我們在瀏覽器中輸入URL www.sample.com,因為它僅僅是對頁面的簡單請求無需對資料庫動進行動態請求,所以它不存在SQL Injection,當我們輸入www.sample.com?testid=23時,我們在URL中傳遞變數testid,而且提供值為23,因為它是對資料庫進行動態查詢的請求(當中?testid=23表示資料庫查詢變數),所以我們能夠該URL中嵌入惡意SQL語句。
如今我們知道SQL Injection適用場合,接下來我們將通過詳細的樣例來說明SQL Injection的應用,這裡我們以pubs資料庫作為樣例。
我們通過Web頁面查詢job表中的招聘資訊,job表的設計例如以下:
圖1 jobs表
接著讓我們實現Web程式,它依據工作Id(job_id)來查詢對應的招聘資訊,示意程式碼例如以下:
/// <summary> /// Handles the Load event of the Page control. /// </summary> /// <param name="sender">The source of the event.</param> /// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param> protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { // Gets departmentId from http request. string queryString = Request.QueryString["departmentID"]; if (!string.IsNullOrEmpty(queryString)) { // Gets data from database. gdvData.DataSource = GetData(queryString.Trim()); // Binds data to gridview. gdvData.DataBind(); } } }
如今我們已經完畢了Web程式,接下來讓我們查詢對應招聘資訊吧。
圖2 job表查詢結果
如圖所看到的,我們要查詢資料庫中工作Id值為1的工作資訊,並且在頁面顯示了該工作的Id,Description,Min Lvl和Max Lvl等資訊。
如今要求我們實現依據工作Id查詢對應工作資訊的功能,想必大家非常快能夠給出解決方式,SQL示意程式碼例如以下:
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE (job_id = 1)
如果如今要求我們獲取Department表中的全部資料,並且必須保留WHERE語句,那我們僅僅要確保WHERE恆真就OK了,SQL示意程式碼例如以下:
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE (job_id = 1) OR 1 = 1
上面我們使得WHERE恆真,所以該查詢中WHERE已經不起作用了,其查詢結果等同於下面SQL語句。
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs
SQL查詢程式碼實現例如以下:
string sql1 = string.Format( "SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='{0}'", jobId);
如今我們要通過頁面請求的方式,讓資料庫執行我們的SQL語句,我們要在URL中嵌入惡意表示式1=1(或2=2等等),例如以下URL所看到的:
http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1
等效SQL語句例如以下:
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id = '1' OR '1' = 1'
圖3 job表查詢結果
如今我們把job表中的全部資料都查詢出來了,只通過一個簡單的恆真表示式就能夠進行了一次簡單的攻擊。
儘管我們把job表的資料都查詢出來了,但資料並沒有太大的價值,因為我們把該表暫時命名為job表,所以接著我們要找出該表真正表名。
首先我們如果表名就是job,然後輸入下面URL:
http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or 1=(select count(*) from job)--
等效SQL語句例如以下:
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='1'or 1=(select count(*) from job) --'
圖4 job表查詢結果
當我們輸入了以上URL後,結果server返回我們錯誤資訊,這證明了我們的如果是錯誤的,那我們該感覺到挫敗嗎?不,事實上這裡返回了非常多資訊,首先它證明了該表名不是job,並且它還告訴我們後臺資料庫是SQL Server,不是MySQL或Oracle,這也設計一個漏洞把錯誤資訊直接返回給了使用者。
接下假定表名是jobs,然後輸入下面URL:
http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or1=(select count(*) from jobs) --
等效SQL語句例如以下:
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='1'or 1=(select count(*) from jobs) --'
圖5 job表查詢結果
如今證明了該表名是jobs,這能夠邁向成功的一大步,因為我們知道了表名就能夠對該表進行增刪改操作了,並且我們還能夠推測出很多其它的表對它們作出改動,一旦改動成功那麼這將是一場災難。
如今大家已經對SQL Injection的攻擊有了初步的瞭解了,接下讓我們學習怎樣防止SQL Injection。
總的來說有下面幾點:
1.永遠不要信任使用者的輸入,要對使用者的輸入進行校驗,能夠通過正規表示式,或限制長度,對單引號和雙"-"進行轉換等。
2.永遠不要使用動態拼裝SQL,能夠使用引數化的SQL或者直接使用儲存過程進行資料查詢存取。
3.永遠不要使用管理員許可權的資料庫連線,為每一個應用使用單獨的許可權有限的資料庫連線。
4.不要把機密資訊明文存放,請加密或者hash掉password和敏感的資訊。
5.應用的異常資訊應該給出儘可能少的提示,最好使用自己定義的錯誤資訊對原始錯誤資訊進行包裝,把異常資訊存放在獨立的表中。
通過正則表達校驗使用者輸入
首先我們能夠通過正規表示式校驗使用者輸入資料中是包括:對單引號和雙"-"進行轉換等字元。
然後繼續校驗輸入資料中是否包括SQL語句的保留字,如:WHERE,EXEC,DROP等。
如今讓我們編寫正規表示式來校驗使用者的輸入吧,正規表示式定義例如以下:
private static readonly Regex RegSystemThreats = new Regex(@"\s?or\s*|\s?;\s?|\s?drop\s|\s?grant\s|^'|\s?--|\s?union\s|\s?delete\s|\s?truncate\s|" + @"\s?sysobjects\s?|\s?xp_.*?|\s?syslogins\s?|\s?sysremote\s?|\s?sysusers\s?|\s?sysxlogins\s?|\s?sysdatabases\s?|\s?aspnet_.*?|\s?exec\s?", RegexOptions.Compiled | RegexOptions.IgnoreCase);
上面我們定義了一個正規表示式物件RegSystemThreats,而且給它傳遞了校驗使用者輸入的正規表示式。
因為我們已經完畢了對使用者輸入校驗的正規表示式了,接下來就是通過該正規表示式來校驗使用者輸入是否合法了,因為.NET已經幫我們實現了推斷字串是否匹配正規表示式的方法——IsMatch(),所以我們這裡僅僅需給傳遞要匹配的字串就OK了。
示意程式碼例如以下:
/// <summary> /// A helper method to attempt to discover [known] SqlInjection attacks. /// </summary> /// <param name="whereClause">string of the whereClause to check</param> /// <returns>true if found, false if not found </returns> public static bool DetectSqlInjection(string whereClause) { return RegSystemThreats.IsMatch(whereClause); } /// <summary> /// A helper method to attempt to discover [known] SqlInjection attacks. /// </summary> /// <param name="whereClause">string of the whereClause to check</param> /// <param name="orderBy">string of the orderBy clause to check</param> /// <returns>true if found, false if not found </returns> public static bool DetectSqlInjection(string whereClause, string orderBy) { return RegSystemThreats.IsMatch(whereClause) || RegSystemThreats.IsMatch(orderBy); }
如今我們完畢了校驗用的正規表示式,接下來讓我們須要在頁面中加入�校驗功能。
/// <summary> /// Handles the Load event of the Page control. /// </summary> /// <param name="sender">The source of the event.</param> /// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param> protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { // Gets departmentId from http request. string queryString = Request.QueryString["jobId"]; if (!string.IsNullOrEmpty(queryString)) { if (!DetectSqlInjection(queryString) && !DetectSqlInjection(queryString, queryString)) { // Gets data from database. gdvData.DataSource = GetData(queryString.Trim()); // Binds data to gridview. gdvData.DataBind(); } else { throw new Exception("Please enter correct field"); } } } }
當我們再次執行下面URL時,被嵌入的惡意語句被校驗出來了,從而在一定程度上防止了SQL Injection。
http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1
圖6 加入�校驗查詢結果
但使用正規表示式僅僅能防範一些常見或已知SQL Injection方式,並且每當發現有新的攻擊方式時,都要對正規表示式進行改動,這但是吃力不討好的工作。
通過引數化儲存過程進行資料查詢存取
首先我們定義一個儲存過程依據jobId來查詢jobs表中的資料。
-- ============================================= -- Author: JKhuang -- Create date: 12/31/2011 -- Description: Get data from jobs table by specified jobId. -- ============================================= ALTER PROCEDURE [dbo].[GetJobs] -- ensure that the id type is int @jobId INT AS BEGIN -- SET NOCOUNT ON; SELECT job_id, job_desc, min_lvl, max_lvl FROM dbo.jobs WHERE job_id = @jobId GRANT EXECUTE ON GetJobs TO pubs END
接著改動我們的Web程式使用引數化的儲存過程進行資料查詢。
using (var com = new SqlCommand("GetJobs", con)) { // Uses store procedure. com.CommandType = CommandType.StoredProcedure; // Pass jobId to store procedure. com.Parameters.Add("@jobId", SqlDbType.Int).Value = jobId; com.Connection.Open(); gdvData.DataSource = com.ExecuteScalar(); gdvData.DataBind(); }
如今我們通過引數化儲存過程進行資料庫查詢,這裡我們把之前加入�的正規表示式校驗凝視掉。
圖7 儲存過程查詢結果
大家看到當我們試圖在URL中嵌入惡意的SQL語句時,引數化儲存過程已經幫我們校驗出傳遞給資料庫的變數不是整形,並且使用儲存過程的優點是我們還能夠非常方便地控制使用者許可權,我們能夠給使用者分配僅僅讀或可讀寫許可權。
但我們想想真的有必要每一個資料庫操作都定義成儲存過程嗎?並且那麼多的儲存過程也不利於日常的維護。
引數化SQL語句
還是回到之前動態拼接SQL基礎上,我們知道一旦有惡意SQL程式碼傳遞過來,並且被拼接到SQL語句中就會被資料庫執行,那麼我們能否夠在拼接之前進行推斷呢?——命名SQL引數。
string sql1 = string.Format("SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id = @jobId"); using (var con = new SqlConnection(ConfigurationManager.ConnectionStrings["SQLCONN1"].ToString())) using (var com = new SqlCommand(sql1, con)) { // Pass jobId to sql statement. com.Parameters.Add("@jobId", SqlDbType.Int).Value = jobId; com.Connection.Open(); gdvData.DataSource = com.ExecuteReader(); gdvData.DataBind(); }
圖8 引數化SQL查詢結果
這樣我們就能夠避免每一個資料庫操作(尤其一些簡單資料庫操作)都編寫儲存過程了,並且當使用者具有資料庫中jobs表的讀許可權才幹夠執行該SQL語句。
加入�新架構
資料庫架構是一個獨立於資料庫使用者的非反覆名稱空間,您能夠將架構視為物件的容器(類似於.NET中的名稱空間)。
首先我們右擊架構目錄,然後新建架構。
圖9 加入�HumanResource架構
上面我們完畢了在pubs資料庫中加入�HumanResource架構,接著把jobs表放到HumanResource架構中。
圖 10 改動jobs表所屬的架構
當我們再次執行下面SQL語句時,SQL Server提示jobs無效,這是到底什麼原因呢?之前還執行的好好的。
SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs
圖 11 查詢輸出
當我們輸入完整的表名“架構名.物件名”(HumanResource.jobs)時,SQL語句執行成功。
SELECT job_id, job_desc, min_lvl, max_lvl FROM HumanResource.jobs
為什麼之前我們執行SQL語句時不用輸入完整表名dbo.jobs也能夠執行呢?
這是由於預設的架構(default schema)是dbo,當僅僅輸入表名時,Sql Server會自己主動加上當前登入使用者的預設的架構(default schema)——dbo。
因為我們使用自己定義架構,這也減少了資料庫表名被推測出來的可能性。
LINQ to SQL
前面使用了儲存過程和引數化查詢,這兩種方法都是非經常常使用的,而針對於.NET Framework的ORM框架也有非常多,如:NHibernate,Castle和Entity Framework,這裡我們使用比較簡單LINQ to SQL。
圖 12 加入�jobs.dbml檔案
var dc = new pubsDataContext(); int result; // Validates jobId is int or not. if (int.TryParse(jobId, out result)) { gdvData.DataSource = dc.jobs.Where(p => p.job_id == result); gdvData.DataBind(); }
相比儲存過程和引數化查詢,LINQ to SQL我們僅僅需加入�jobs.dbml,然後使用LINQ對錶進行查詢就OK了。
1.1.3 總結
我們在本文中介紹了SQL Injection的基本原理,通過介紹什麼是SQL Injection,如何進行SQL Injection和如何防範SQL Injection。通過一些程式原始碼對SQL的攻擊進行了仔細的分析,使我們對SQL Injection機理有了一個深入的認識,作為一名Web應用開發者,一定不要盲目相信使用者的輸入,而要對使用者輸入的資料進行嚴格的校驗處理,否則的話,SQL Injection將會不期而至。
最後,祝大家新年快樂,身體健康,Code with pleasure。