SQL Injection

關(guān)于sql注入的危害在這里就不多做介紹了，相信大家也知道其中的厲害關(guān)系。這里有一些sql注入的事件大家感興趣可以看一下

防范sql注入的方法無非有以下幾種：

1.使用類型安全的SQL參數(shù)2.使用參數(shù)化輸入存儲過程3.使用參數(shù)集合與動態(tài)SQL4.輸入濾波5.過濾LIKE條款的特殊字符

...如果有遺漏的也歡迎園子的大大們指教。

Sample:

var Shipcity;ShipCity = Request.form ("ShipCity");var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

上面是一個簡單的sql注入示例

用戶將被提示輸入一個市縣名稱。如果用戶輸入Redmond，則查詢將由與下面內(nèi)容相似的腳本組成：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

但是，假定用戶輸入以下內(nèi)容：

Redmond'; drop table OrdersTable--

此時，腳本將組成以下查詢：

1 SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

分號 (;) 表示一個查詢的結(jié)束和另一個查詢的開始。雙連字符 (--) 指示當(dāng)前行余下的部分是一個注釋，應(yīng)該忽略。如果修改后的代碼語法正確，則服務(wù)器將執(zhí)行該代碼。SQL Server 處理該語句時，SQL Server 將首先選擇OrdersTable中的所有記錄（其中ShipCity為Redmond）。然后，SQL Server 將刪除OrdersTable。

只要注入的 SQL 代碼語法正確，便無法采用編程方式來檢測篡改。因此，必須驗(yàn)證所有用戶輸入，并仔細(xì)檢查在您所用的服務(wù)器中執(zhí)行構(gòu)造 SQL 命令的代碼。本主題中的以下各部分說明了編寫代碼的最佳做法。

• 對應(yīng)用程序接收的數(shù)據(jù)不做任何有關(guān)大小、類型或內(nèi)容的假設(shè)。例如，您應(yīng)該進(jìn)行以下評估：

  • 如果一個用戶在需要郵政編碼的位置無意中或惡意地輸入了一個 10 MB 的 MPEG 文件，應(yīng)用程序會做出什么反應(yīng)？

  • 如果在文本字段中嵌入了一個 DROP TABLE 語句，應(yīng)用程序會做出什么反應(yīng)？

• 測試輸入的大小和數(shù)據(jù)類型，強(qiáng)制執(zhí)行適當(dāng)?shù)南拗啤＿@有助于防止有意造成的緩沖區(qū)溢出。

• 測試字符串變量的內(nèi)容，只接受所需的值。拒絕包含二進(jìn)制數(shù)據(jù)、轉(zhuǎn)義序列和注釋字符的輸入內(nèi)容。這有助于防止腳本注入，防止某些緩沖區(qū)溢出攻擊。

• 使用 xml 文檔時，根據(jù)數(shù)據(jù)的架構(gòu)對輸入的所有數(shù)據(jù)進(jìn)行驗(yàn)證。

• 絕不直接使用用戶輸入內(nèi)容來生成 Transact-SQL 語句。

• 使用存儲過程來驗(yàn)證用戶輸入。

• 在多層環(huán)境中，所有數(shù)據(jù)都應(yīng)該在驗(yàn)證之后才允許進(jìn)入可信區(qū)域。未通過驗(yàn)證過程的數(shù)據(jù)應(yīng)被拒絕，并向前一層返回一個錯誤。

• 實(shí)現(xiàn)多層驗(yàn)證。對無目的的惡意用戶采取的預(yù)防措施對堅定的攻擊者可能無效。更好的做法是在用戶界面和所有跨信任邊界的后續(xù)點(diǎn)上驗(yàn)證輸入。

  例如，在客戶端應(yīng)用程序中驗(yàn)證數(shù)據(jù)可以防止簡單的腳本注入。但是，如果下一層認(rèn)為其輸入已通過驗(yàn)證，則任何可以繞過客戶端的惡意用戶就可以不受限制地訪問系統(tǒng)。

• 絕不串聯(lián)未驗(yàn)證的用戶輸入。字符串串聯(lián)是腳本注入的主要輸入點(diǎn)。

• 在可能據(jù)以構(gòu)造文件名的字段中，不接受下列字符串：AUX、CLOCK$、COM1 到 COM8、CON、CONFIG$、LPT1 到 LPT8、NUL 以及 PRN。

如果可能，拒絕包含以下字符的輸入。

注：驗(yàn)證輸入是最被常用和聯(lián)想到的，但是個人感覺這種方式不但代碼顯得肥胖，而且效率不是很好

SQL Server 中的Parameters集合提供了類型檢查和長度驗(yàn)證。如果使用Parameters集合，則輸入將被視為文字值而不是可執(zhí)行代碼。使用Parameters集合的另一個好處是可以強(qiáng)制執(zhí)行類型和長度檢查。范圍以外的值將觸發(fā)異常。以下代碼段顯示了如何使用Parameters集合：

1 SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);2 myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;3 SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",4      SqlDbType.VarChar, 11);5 parm.Value = Login.Text;

在此示例中，@au_id參數(shù)被視為文字值而不是可執(zhí)行代碼。將對此值進(jìn)行類型和長度檢查。如果@au_id值不符合指定的類型和長度約束，則將引發(fā)異常。

存儲過程如果使用未篩選的輸入，則可能容易受 SQL Injection 攻擊。例如，以下代碼容易受到攻擊：

如果使用存儲過程，則應(yīng)使用參數(shù)作為存儲過程的輸入。

注：在鄙人現(xiàn)在的項目中，這種方法應(yīng)用最為廣泛

如果不能使用存儲過程，您仍可使用參數(shù)，如以下代碼示例所示：

1 SqlDataAdapter myCommand = new SqlDataAdapter(2 "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn);3 SQLParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", 4                         SqlDbType.VarChar, 11);5 Parm.Value = Login.Text;

注：和第二種雷同，這種方法是為了補(bǔ)充方法2存在，因?yàn)橥诤芏鄷r候業(yè)務(wù)簡單不需要用proc的時候，可以用這種方法

篩選輸入可以刪除轉(zhuǎn)義符，這也可能有助于防止 SQL 注入。但由于可引起問題的字符數(shù)量很大，因此這并不是一種可靠的防護(hù)方法。以下示例可搜索字符串分隔符。

1 private string SafeSqlLiteral(string inputSQL)2 {3   return inputSQL.Replace("'", "''");4 }

注：Filtering Input有種類似方法1

請注意，如果要使用 LIKE 子句，還必須對通配符字符進(jìn)行轉(zhuǎn)義：

1  2 s = s.Replace("[", "[[]");3 s = s.Replace("%", "[%]");4 s = s.Replace("_", "[_]");

注：針對like子句，在使用時的效率這里就不多說了，總之要慎用了。

以上所有方法及其注釋高亮顯示部分，均為本人愚見，如果對方法有補(bǔ)充或者對高亮部分有不同意見的，歡迎大家給出意見，共同進(jìn)步.

本文是在借鑒MSDN的前提下加了一些自己的理解與意見， 轉(zhuǎn)載請注入出處。 thx.

if您看了這篇博客。對您有所幫助，請不要吝嗇您的“推薦”，您的推薦將是我最大的動力。有問題的話可以評論交流。