LINQ - 對付 SQL Injection 的 "免費補洞策略"

LINQ - 對付 SQL Injection 的 "免費補洞策略"

作者：黃忠成

一連串的 Mass SQL Injection 攻擊，讓我們回憶起數(shù)年前的 SQL Injection 攻擊，多年後的今天，我們?nèi)陨钕蒽锻瑯拥奈C中，本文詳述 SQL Injection 的歷史、肇因、解決及偵測方法，更為讀者們引介全新、更加安全的防堵 SQL Injection 策略。

什麼是 SQL Injection？

SQL Injection，中譯為 SQL 注入，更為人知的名稱是【資料隱碼攻擊】，意指開發(fā)人員於撰寫網(wǎng)頁應(yīng)用程式之際，貪圖一時方便或是依循前人的慣性寫法而開啟的一道門。在數(shù)年前，一次大型的隱碼攻擊行動，喚起了所有網(wǎng)站擁有者及設(shè)計人員的防駭之心，讓我們認(rèn)知到，網(wǎng)站是一個曝露在所有人面前的公共園地，其安全性不容忽視！在那次的攻擊行動中，有數(shù)千個網(wǎng)站遭到同一種手法入侵，洩露的資料及因入侵所損失的金額難以估計，而起源竟只是程式設(shè)計師的慣性及疏於防範(fàn)，而我們都曾經(jīng)是其中一份子。

那具體上，什麼是 SQL Injection 呢？其實說穿了很簡單，就是透過網(wǎng)頁上的輸入?yún)^(qū)域 (INPUT 如文字輸入框，或是 URL 中的查詢字串)，將特定的 SQL 語句透過網(wǎng)頁送往資料庫執(zhí)行。以一個登入網(wǎng)頁為例，在設(shè)計登入網(wǎng)頁時，我們會放兩個 TextBox 控件，分別讓使用者填入使用者 ID 及密碼，類似畫面如下：

圖 1：

在使用者按下登入按鈕後，我們將其輸入的資訊送往資料庫，驗證使用者輸入的登入資訊是否正確：

using System; using System.Configuration; using System.Data; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Data.SqlClient; public partial class _Default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } protected void Button1_Click(object sender, EventArgs e) { if (ValidateUser(TextBox1.Text, TextBox2.Text)) Label1.Text = "歡迎你"; else Label1.Text = "登入失敗"; } private bool ValidateUser(string userName, string password) { SqlConnection conn = new SqlConnection( "Data Source=JEFFRAY;Initial Catalog=Northwind;Integrated Security=True"); using (conn) { SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM USERS WHERE USER_ID = '" + userName + "' AND PASSWORD = '" + password + "'", conn); conn.Open(); return ((int)cmd.ExecuteScalar() > 0); } } }

當(dāng)你寫下這些程式碼時，已經(jīng)開啟了 SQL Injection 的大門了，只要使用者於登入時，填入下圖的資訊，那麼不管 ID 密碼是什麼，一律可以登入系統(tǒng)。

圖 2：

這是為什麼呢？很簡單，起因於下面這行程式碼：

SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM USERS WHERE USER_ID = '" + userName + "' AND PASSWORD = '" + password + "'", conn);

我們使用傳統(tǒng) ASP 常見的手法，以組裝 SQL 指令的方式，將使用者的輸入融入既定的 SQL 語句中，但卻忽略了一件重要的事：使用者可以輸入任意的字串，包括了部份的 SQL 指令！透過輸入部份的 SQL 指令及微調(diào)，使用者可以輕易的改變這段 SQL 指令，甚至是疊加另一串 SQL 指令，而我們的網(wǎng)頁則照單全收，以上的輸入，會將整句 SQL 語句調(diào)整成下面這樣：

圖 3：

透過必然成真的條件式，再加上 SQL 的註解，我們的網(wǎng)站就這樣曝露在網(wǎng)路上，今天我加的是 OR，若是狠一點的加上 DROP TABLE 等破壞性指令，網(wǎng)站就此拜拜。

這種攻擊不僅僅出現(xiàn)在上例這種 POST 狀況，另一種 GET 狀態(tài)也常常受到同樣的攻擊，例如下面的程式碼即開啟了 SQL Injection 的大門。

using System; using System.Collections; using System.Configuration; using System.Data; using System.Linq; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Data.SqlClient; public partial class QueryStringInjection : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { SqlConnection conn = new SqlConnection("Data Source=JEFFRAY;Initial Catalog=Northwind;Integrated Security=True"); using (conn) { SqlCommand cmd = new SqlCommand( "SELECT * FROM Customers WHERE CustomerID = '"+Request.QueryString["ID"]+"'", conn); conn.Open(); DetailsView1.DataSource = cmd.ExecuteReader(CommandBehavior.CloseConnection); DetailsView1.DataBind(); } } } }

試著在 URL 上鍵入：

http://localhost:43236/FirstInjection/QueryStringInjection.aspx?ID=VINET' OR 1=1 --

註：http://localhost:43236 是你的 Web Development Server 自動產(chǎn)生的 Port，你必須視情況修改。

結(jié)果你會看到 CustomerID="VINET" 以外的 ALFKI 資料列，如下圖：

圖 4：

如果有心人士在 URL 上鍵入 DROP TABLE 或是 INSERT 的 QueryString，將資料任意的刪除或插入惡意的連結(jié) Script (詳見後述的 Mass SQL Injection 一節(jié))，那後果不堪設(shè)想。

未啟用 Custom Error Page 的漏洞

你應(yīng)該已經(jīng)知道，寫 ASP.NET 應(yīng)用程式的第一道安全手續(xù)就是啟用 Custom Error Page 功能，讓駭客們無法透過預(yù)設(shè)的錯誤網(wǎng)頁來取得不該取得的資訊，若未啟用 Custom Error Page，那麼下圖是可能發(fā)生在你的網(wǎng)站中的：

圖 5：

有了這些資訊，具有耐心的駭客，要透過輸入不同的字元來探測整段 SQL 語句就不困難了，防堵的最佳辦法就是啟用 Custom Error Page 設(shè)定：

Web.config

...............略<customErrors mode="On" defaultRedirect="DefaultError.htm"></customErrors>............略

一旦啟用後，錯誤發(fā)生時會導(dǎo)向 DefaultError.html，結(jié)果變成下面這樣：

圖 6：

檢測你的網(wǎng)頁有無 SQL Injection 的可能性

OK，那有沒有辦法可以檢測現(xiàn)在的網(wǎng)頁是否受 SQL Injection 威脅呢？如果你是網(wǎng)站管理者，而非設(shè)計師，那麼你只有依賴現(xiàn)在常見的網(wǎng)頁漏洞檢測工具，對網(wǎng)頁進行黑箱測試，不過提醒你，目前的網(wǎng)頁漏洞測試工具大多是針對 PHP、ASP 所設(shè)計的，能測出來的漏洞相當(dāng)有限，有時即使是安全的網(wǎng)頁，也會因為未實作過濾法(後述)，而導(dǎo)致誤判。

如果你是程式設(shè)計師，事情就簡單的多了，只要檢視一下程式碼，看看動態(tài)組裝 SQL 語句的部份是否有 SQL Injection 即可，圖 007 是一個確認(rèn) SQL Injection 是否存在於你的程式中的公式。

圖 7：

只要你的程式中，有 SQL 字串加上使用者輸入值的情況，那麼該網(wǎng)頁存在 SQL Injection 危機的可能性就高達 99.9%。

前輩的叮嚀：防止 SQL Injection 的方法

在數(shù)千個網(wǎng)站的入侵事件發(fā)生後，許多資安專家提出了各種防範(fàn) SQL Injection 的方法，其中不外乎圖 008 的四種。

圖 8：

過濾法可以阻止特定字如【--】、【 OR 】、【'】的輸入，能有效防堵必然成真條件式及錯誤訊息顯示時的漏洞，不過魔高一丈，此法最後仍然遭受破解，透過 SQL 的轉(zhuǎn)碼函式，駭客可以將部份 SQL 語句做出編碼來逃避偵測，最後突破這道防線。但由於轉(zhuǎn)碼後的字串相當(dāng)長，所以只要設(shè)計師細(xì)心些，搭配 MaxLength 的設(shè)定，還是可以讓過濾法奏效，但過濾法其實很脆弱，所以一定要搭配其它的手法方能行之。

下面是一個使用過濾法的例子，利用引入外部 JavaScript 檔案及 Form 的 onSubmit 事件，在送出資料前先檢測擁有 ci Attribute 標(biāo)示的 text tag，此法可運行於 IE 及 FireFox 上：

Injectiondetect.js

function validateInjection() { var i = 0; for(i = 0; i < document.forms[0].elements.length;i++) { if(document.forms[0].elements[i].type == 'text' && document.forms[0].elements[i].getAttribute("ci") != null) { var elem = document.forms[0].elements[i]; if(elem.value != null && (elem.value.indexOf('\'') != -1 || elem.value.indexOf('--') != -1 || elem.value.indexOf(' OR ') != -1)) { alert('possible injection detected.') return false; } } } return true; }

.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="DefaultWithFilter.aspx.cs" Inherits="DefaultWithFilter" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>Untitled Page</title> <script language='javascript' type="text/javascript" src='injectiondetect.js'> </script> </head> <body> <form id="form1" οnsubmit="return validateInjection()" runat="server"> <div> <table border="1"> <tr> <td>使用者編號</td> <td><asp:TextBox ID="TextBox1" ci="true" MaxLength="12" runat="server"></asp:TextBox></td> </tr> <tr> <td>密碼</td> <td><asp:TextBox ID="TextBox2" ci="true" MaxLength="12" runat="server"></asp:TextBox></td> </tr> <tr> <td colspan=2> <asp:Button ID="Button1" runat="server" Text="登入" οnclick="Button1_Click" /> </td> </tr> </table> <asp:Label ID="Label1" runat="server" Text=""></asp:Label> </div> </form> </body> </html>

下圖是嘗試於此網(wǎng)頁進行 SQL Injection 攻擊時的結(jié)果：

圖 9：

不過，這種過濾法還不完善，因為資深的駭客仍然可以透過將網(wǎng)頁存成 HTML，移除 JavaScript 認(rèn)證並假造 ViewState 來對網(wǎng)站進行 SQL Injection 攻擊！所以，完善的過濾法應(yīng)該是 Client 端與 Server 都有，Server 端如下所示：

.aspx.cs

using System; using System.Collections; using System.Configuration; using System.Data; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Data.SqlClient; public partial class DefaultWithFilter : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } private bool DetectInjection(string input) { if (input.IndexOf("'") != -1 || input.IndexOf("--") != -1 || input.IndexOf(" OR ") != -1) return true; return false; } protected void Button1_Click(object sender, EventArgs e) { if (TextBox1.Text.Length > 12 || TextBox2.Text.Length > 12 || DetectInjection(TextBox1.Text) || DetectInjection(TextBox2.Text)) { ClientScript.RegisterStartupScript(typeof(Page), "Alert_Msg", "alert('possible injection detected.')", true); return; } if (ValidateUser(TextBox1.Text, TextBox2.Text)) Label1.Text = "歡迎你"; else Label1.Text = "登入失敗"; } private bool ValidateUser(string userName, string password) { SqlConnection conn = new SqlConnection( "Data Source=JEFFRAY;Initial Catalog=Northwind;Integrated Security=True"); using (conn) { SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM USERS WHERE USERS.USER_ID = '" + userName + "' AND USERS.PASSWORD = '" + password + "'", conn); conn.Open(); return ((int)cmd.ExecuteScalar() > 0); } } }

或許你會覺得實作起來挺麻煩的，但這是過濾法所需付出的代價！

除了過濾法外，使用低權(quán)限的帳號連結(jié)資料庫也是安全常識之一，藉由降低連線帳號的權(quán)限，可以讓 DROP TABLE 等破壞力超強的手法碰壁，不過這種手法不應(yīng)該成為唯一防堵 SQL Injection 的方式，因為你不可能連 INSERT 都不給執(zhí)行，而 INSERT 是駭客入侵網(wǎng)頁的常見手法。

使用 Parameter 是目前已知，一勞永逸逃離 SQL Injection 的手法，將前述的程式調(diào)整成下面這樣，即可讓其完全逃離 SQL Injection。

using System; using System.Collections; using System.Configuration; using System.Data; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Data.SqlClient; public partial class Default2 : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } protected void Button1_Click(object sender, EventArgs e) { if (ValidateUser(TextBox1.Text, TextBox2.Text)) Label1.Text = "歡迎你"; else Label1.Text = "登入失敗"; } private bool ValidateUser(string userName, string password) { SqlConnection conn = new SqlConnection( "Data Source=JEFFRAY;Initial Catalog=Northwind;Integrated Security=True"); using (conn) { SqlCommand cmd = new SqlCommand( "SELECT COUNT(*) FROM USERS WHERE USER_ID = @USER_ID AND PASSWORD = @PASSWORD", conn); cmd.Parameters.AddWithValue("@USER_ID", userName); cmd.Parameters.AddWithValue("@PASSWORD", password); conn.Open(); return ((int)cmd.ExecuteScalar() > 0); } } }

失效了嗎？這些方法

上節(jié)提及的幾種防堵 SQL Injection 的方法，在業(yè)界已經(jīng)流傳許久，其中使用 Parameter 更是快變成常識級的考古用知識。那為何到目前為止，你仍然時常聽到某某網(wǎng)站遭受 SQL Injection 攻擊，甚至！你只要有足夠的時間及耐心，用 Google 以關(guān)鍵字【登入】、【資料查詢】查詢，接著以上述的【' OR 1=1 --】或是【'】來一一測試，輕輕鬆鬆就能找到幾個吃這套技巧的網(wǎng)站，然後取得極度敏感的個人資料或是其用來查詢的 SQL 字串。

SQL Injection 至今仍然存在的原因很簡單，程式設(shè)計師的惰性、慣性及大而化之的個性，是導(dǎo)致 SQL Injection 存在於這個高安全性當(dāng)?shù)罆r代的最大原因。

雖然使用 Parameter 手法可以防掉所有的 SQL Injection 攻擊，但在此同時，也增加了需要撰寫的程式碼長度，常見的結(jié)果便是設(shè)計師只會在特定敏感功能上，才會使用這種手法。

在現(xiàn)時今日，你很難當(dāng)起駭客，透過 SQL Injection 手法通過極大多數(shù)網(wǎng)站的【登入】機制，原因不是程式設(shè)計師及網(wǎng)站管理者的細(xì)心，而是這個機制曾經(jīng)出了個所有人都無法忽視的大包， 但 SQL Injection 只出現(xiàn)在這些機制上嗎？你我都知道，這不是真的，舉個實例來說，以下的查詢網(wǎng)頁是相當(dāng)常見的。

圖 10：

這個網(wǎng)頁允許使用者任意輸入【公司名稱】、【客戶編號】、【聯(lián)絡(luò)人】等三個欄位之搜尋字串，然後進行組合查詢，如果使用者僅輸入【公司名稱】，那麼系統(tǒng)將不會把其它兩個欄位放入查詢語句中，請先閉上眼睛，思考著你怎麼實現(xiàn)這個功能，如果結(jié)果是下面這樣，那你已然開啟 SQL Injection 的大門了。

protected void Button1_Click(object sender, EventArgs e) { SqlConnection conn = new SqlConnection( "Data Source=JEFFRAY;Initial Catalog=Northwind;Integrated Security=True"); using (conn) { SqlCommand cmd = new SqlCommand("SELECT * FROM Customers", conn); string cmdStr = ""; if(TextBox1.Text.Length > 0) cmdStr += string.Format(" CompanyName LIKE '%{0}%' AND ",TextBox1.Text); if(TextBox2.Text.Length > 0) cmdStr += string.Format(" CustomerID LIKE '%{0}%' AND ",TextBox2.Text); if(TextBox3.Text.Length > 0) cmdStr += string.Format(" ContactTitle LIKE '%{0}%' AND ",TextBox3.Text); if (cmdStr.Length > 0) cmd.CommandText += " WHERE " + cmdStr.Substring(0, cmdStr.Length - 5); conn.Open(); GridView1.DataSource = cmd.ExecuteReader(CommandBehavior.CloseConnection); GridView1.DataBind(); } }

導(dǎo)致我們寫下這個程式的原因有三個：

圖 11：

第三個原因大概是寫下此程式之設(shè)計師真正的想法，那會變多長呢？我們試著寫一下就知道了。

protected void Button1_Click(object sender, EventArgs e) { SqlConnection conn = new SqlConnection( "Data Source=JEFFRAY;Initial Catalog=Northwind;Integrated Security=True"); using (conn) { SqlCommand cmd = new SqlCommand("SELECT * FROM Customers", conn); string cmdStr = ""; if (TextBox1.Text.Length > 0) { cmdStr += " CompanyName LIKE @CName AND "; cmd.Parameters.AddWithValue("@CName", "%"+TextBox1.Text+"%"); } if (TextBox2.Text.Length > 0) { cmdStr += " CustomerID LIKE @CID AND "; cmd.Parameters.AddWithValue("@CID", "%" + TextBox2.Text + "%"); } if (TextBox3.Text.Length > 0) { cmdStr += " ContactTitle LIKE @CTitle AND "; cmd.Parameters.AddWithValue("@CTitle", "%" + TextBox3.Text + "%"); } if (cmdStr.Length > 0) cmd.CommandText += " WHERE " + cmdStr.Substring(0, cmdStr.Length - 5); conn.Open(); GridView1.DataSource = cmd.ExecuteReader(CommandBehavior.CloseConnection); GridView1.DataBind(); } }

唔，也不是很長嘛，為了省幾行程式碼開這麼大的洞，值得嗎？呵，程式設(shè)計師就是這種動物，不是嗎？

補洞的代價

在你暗笑著，我怎麼可能會犯下前節(jié)的錯誤時，我必須提醒你程式設(shè)計師的第二個通病，那就是【以己度人】，白話就是【我不會犯的錯，所以別人也不會犯】，在群組開發(fā)時，這個情況更是履見不鮮。事實是，你不會寫下這段程式碼，但難保其它設(shè)計師不會，畢竟都是糊口飯吃的，只要補洞的工作需要付出時間代價，那麼就一定有人會偷懶或粗心，肇因可能是惰性、慣性，也可能是你未跟他明確提及這事兒的嚴(yán)重性，而後果常是我們無法承受的。

LINQ To SQL/LINQ To Entities = "免費的補洞策略"

除了程式設(shè)計師努力的防堵 SQL Injection 之外，開發(fā)平臺廠商也沒有置身事外，以 Microsoft .NET 平臺來說，為了防堵 SQL Injection，ASP.NET Team 於 ASP.NET 2.0 推出了 DataSource 控件群，這組控件利用了 Parameter 的手法，完全避開了 SQL Injection 的發(fā)生。但是我依舊時常聽到許多設(shè)計師抱怨：【DataSource 控件用起來綁手綁腳的，內(nèi)部不知道在搞什麼，還不如自己用 SqlCommand 來得快且直覺。】，的確，事實是如此，DataSource 控件為了防堵 SQL Injection 所做的努力，換來的是【綁手綁腳】的惡名，這該歸咎於 ASP.NET Team 設(shè)計 DataSource 控件時，沒有多花點心思在易用性、安全性、彈性上取得平衡點。

終於，在 .NET Framework 3.5 及 Visual Studio 2008 上市後，兩個免費、快速、有效的補洞策略出現(xiàn)在我們眼前，他們就是【LINQ To SQL/LINQ To Entities】！

說實話！這兩個技術(shù)都不是為了 SQL Injection 而誕生的，但其預(yù)設(shè)以 Parameter 手法運行的設(shè)計，卻給了我們一個新的防堵 SQL Injection 的方法，更好的是，程式設(shè)計師不但不用為了防堵 SQL Injection 寫更多的程式碼，相反的程式碼還變少了，以最初的登入機制為例，用 LINQ To SQL 改寫後變成下面這樣：

using System; using System.Collections; using System.Configuration; using System.Data; using System.Linq; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Xml.Linq; public partial class LoginWithLINQ : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } protected void Button1_Click(object sender, EventArgs e) { NorthwindDataContext context = new NorthwindDataContext(); if( (from s1 in context.USERS where s1.USER_ID == TextBox1.Text && s1.PASSWORD == TextBox2.Text select s1).Count() > 0) Label1.Text = "歡迎你"; else Label1.Text = "登入失敗"; } }

由於 LINQ To SQL 會將 LINQ 運算式轉(zhuǎn)成 SQL 語句，然後將條件式一一以參數(shù)描述之故，透過 SQL Profiler 工具可得知，上面的程式最終送往 SQL Server 執(zhí)行的語句如下：

exec sp_executesql N'SELECT COUNT(*) AS [value] FROM [dbo].[USERS] AS [t0] WHERE ([t0].[USER_ID] = @p0) AND ([t0].[PASSWORD] = @p1)',N'@p0 varchar(5),@p1 varchar(4)',@p0='admin',@p1='test'

很明顯的，這個技巧完全沒有 SQL Injection 的危機存在。

想加來加去，又不要 SQL Injection 嗎？LINQ 做給你

複合查詢常讓設(shè)計師不得不採用組裝式 SQL 語句手法，而其結(jié)果也常因為使用 Parameter 會導(dǎo)致程式碼變複雜，而循傳統(tǒng)手法完成該功能，最後留下 SQL Injection 的漏洞。那使用 LINQ To SQL/LINQ To Entities 來改寫的話，真的可以避免 SQL Injection 及簡化程式碼嗎？讓實例說話吧，我們以上例的複合查詢?yōu)槔?#xff0c;改寫成 LINQ To SQL 版本之程式碼如下 ：

protected void Button1_Click(object sender, EventArgs e) { NorthwindDataContext context = new NorthwindDataContext(); var baseData = from s1 in context.Customers select s1; if(TextBox1.Text.Length > 0) baseData = from s1 in baseData where s1.CompanyName.Contains(TextBox1.Text) select s1; if (TextBox2.Text.Length > 0) baseData = from s1 in baseData where s1.CustomerID.Contains(TextBox2.Text) select s1; if (TextBox3.Text.Length > 0) baseData = from s1 in baseData where s1.ContactTitle.Contains(TextBox3.Text) select s1; GridView1.DataSource = baseData; GridView1.DataBind(); }

此例中，我利用了 LINQ To SQL/LINQ To Entities 只在列舉資料集元素前，才會開始組裝 SQL 語句的共通行為，以疊加式查詢的方式來完成複合查詢的工作，請?zhí)貏e注意，這段程式碼只會送出一段 SQL 語句，不是四個，透過 SQL Profiler 可以證明這點：

exec sp_executesql N'SELECT [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[ContactTitle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Country], [t0].[Phone], [t0].[Fax], [t0].[NOTES], [t0].[TEST_ID] FROM [dbo].[Customers] AS [t0] WHERE ([t0].[CustomerID] LIKE @p0) AND ([t0].[CompanyName] LIKE @p1)',N'@p0 nvarchar(4),@p1 nvarchar(3)',@p0=N'%FR%',@p1=N'%V%'

讓事實說話：LINQ To SQL VS SQL Injection

我說你不一定信，你可以下載範(fàn)例，然後對本文所提及的兩個 LINQ To SQL 網(wǎng)頁進行 SQL Injection 的測試，圖 012 是以【' OR 1=1 --】手法來測試登入機制：

圖 12：

圖 013 是複合查詢的測試：

圖 13：

改用 LINQ To Entities 也是一樣的結(jié)果。

幫幫忙，別自己開洞，ExecuteQuery 及 ExecuteCommand

那使用 LINQ To SQL/LINQ To Entities 就能保證不被 SQL Injection 所擾了嗎？那可不一定，因為設(shè)計師還是常常會貪一時方便，開啟 SQL Injection 的大門。基於彈性，LINQ To SQL 及 LINQ To Entities 都支援直接將 SQL 語句送往資料庫執(zhí)行的機制，LINQ To SQL 的 ExecuteQuery 就是一個例子：

protected void Button1_Click(object sender, EventArgs e) { NorthwindDataContext context = new NorthwindDataContext(); string str = "SELECT * FROM USERS WHERE USER_ID = '" + TextBox1.Text + "' AND PASSWORD = '" + TextBox2.Text + "'"; int ret = context.ExecuteQuery<USERS>(str).Count(); if (ret > 0) Label1.Text = "歡迎你"; else Label1.Text = "登入失敗"; }

所以，要防堵 SQL Injection，使用 LINQ To SQL/LINQ To Entities 是最具成效及具經(jīng)濟效益的，不過前提是設(shè)計師得幫幫忙，別放著有新的方便且有效率的技巧不學(xué)，故意去當(dāng)打洞工人。

迷思：Stored Procedure 是安全的，Parameter 是無敵的？

的確，是我告訴你，使用 Parameter 是防堵 SQL Injection 最快、最有效、最完整的手法，但是前題是不能與 Stored Procedure 扯上關(guān)係！基於網(wǎng)路上的片段資料，設(shè)計師總覺得，如果我使用了 Stored Procedure，並使用 Parameter 來傳遞參數(shù)，那就對 SQL Injection 完全免疫了！所有軟體專案主導(dǎo)者都同意，當(dāng)要求不明確時，結(jié)果也會不明確，基於防堵 SQL Injection 的大前題下，許多專案主導(dǎo)者都會要求設(shè)計師不要在程式中組裝 SQL 語句，而改用 Stored Procedure，但！他們卻高估了程式設(shè)計師的的理解力，天才工程師以 Stored Procedure 來處理複合查詢，寫下程式碼如下：

protected void Button1_Click(object sender, EventArgs e) { SqlConnection conn = new SqlConnection( "Data Source=JEFFRAY;Initial Catalog=Northwind;Integrated Security=True"); using (conn) { SqlCommand cmd = new SqlCommand("QueryCustomers", conn); cmd.CommandType = CommandType.StoredProcedure; cmd.Parameters.AddWithValue("@CompanyName", TextBox1.Text.Length == 0 ? "" : TextBox1.Text); cmd.Parameters.AddWithValue("@CustomerID", TextBox2.Text.Length == 0 ? "" : TextBox2.Text); cmd.Parameters.AddWithValue("@ContactTitle", TextBox3.Text.Length == 0 ? "" : TextBox3.Text); conn.Open(); GridView1.DataSource = cmd.ExecuteReader(CommandBehavior.CloseConnection); GridView1.DataBind(); } }

正如你所見，這是一段看不出問題在那的程式碼，直到看到了 QueryCustomers 的預(yù)存程序，你會吐血：

CREATE PROCEDURE dbo.QueryCustomers ( @CompanyName nvarchar(30), @CustomerID nvarchar(12), @ContactTitle nvarchar(30) ) AS DECLARE @STR nvarchar(255) DECLARE @WK nvarchar(255) SET @STR = 'SELECT * FROM Customers' SET @WK = '' IF NOT @CompanyName IS NULL SET @WK = @WK + ' CompanyName LIKE ''%'+@CompanyName+'%'' AND ' IF NOT @CustomerID IS NULL SET @WK = @WK + ' CustomerID LIKE ''%'+@CustomerID+'%'' AND ' IF NOT @ContactTitle IS NULL SET @WK = @WK + ' ContactTitle LIKE ''%'+@ContactTitle+'%'' AND ' IF LEN(@STR) > 0 BEGIN SET @STR = @STR+' WHERE '+SUBSTRING(@WK,0,LEN(@WK)-3) exec sp_executesql @STR End ELSE exec sp_executesql @STR

結(jié)果就是：

圖 14：

一旦變成這樣，就算是 LINQ To SQL/LINQ To Entities 也無法救你脫離 SQL Injection 的威脅！所以，你應(yīng)該明確的告訴設(shè)計師，SQL Injection 是由組裝式 SQL 語句而引發(fā)的，得注意任何有【組裝式 SQL】發(fā)生的程式碼，這當(dāng)然也包含了 Stored Procedure。此例正確的 Stored Procedure 寫法如下：

CREATE PROCEDURE dbo.SafeQueryCustomers ( @CompanyName nvarchar(30), @CustomerID nvarchar(12), @ContactTitle nvarchar(30) ) AS DECLARE @STR nvarchar(255) DECLARE @WK nvarchar(255) SET @STR = 'SELECT * FROM Customers' SET @WK = '' IF NOT @CompanyName IS NULL BEGIN SET @WK = @WK + ' CompanyName LIKE @pCompanyName AND ' SET @CompanyName = '%' +@CompanyName + '%' END IF NOT @CustomerID IS NULL BEGIN SET @WK = @WK + ' CustomerID LIKE @pCustomerID AND ' SET @CustomerID = '%' +@CustomerID + '%' END IF NOT @ContactTitle IS NULL BEGIN SET @WK = @WK + ' ContactTitle LIKE @pContactTitle AND ' SET @ContactTitle = '%' +@ContactTitle + '%' END IF LEN(@STR) > 0 BEGIN SET @STR = @STR+' WHERE '+SUBSTRING(@WK,0,LEN(@WK)-3) exec sp_executesql @STR, N'@pCompanyName nvarchar(30),@pCustomerID nvarchar(12),@pContactTitle nvarchar(30)', @pCompanyName=@CompanyName,@pCustomerID=@CustomerID,@pContactTitle=@ContactTitle End ELSE exec sp_executesql @STR

使用參數(shù)是防堵 SQL Injection 的不二法門，就算是在 Stored Procedure 中亦是如此。

魔高一丈：新一代的 Mass SQL Injection 手法

網(wǎng)頁的攻擊威脅中，SQL Injection 算是相當(dāng)狠毒的手法，因為破壞性高，所以也就更引人注目，但 SQL Injection 是一種手法的統(tǒng)稱，近日各大報的報導(dǎo)，相信大多人都已見識到新一代的 SQL Injection 手法，統(tǒng)稱為【Mass SQL Injection】。

此手法是利用了傳統(tǒng)的 SQL Injection 為進入點，再利用設(shè)計師對於控件行為的熟悉度不足，及忽視網(wǎng)頁安全性來侵入。舉個例來說，我們常用 GridView 等控件來顯示資料，為了某些理由，我們會直接以方式來輸出列資料，如下所示：

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="InputInjection.aspx.cs" Inherits="InputInjection" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>Untitled Page</title> </head> <body> <form id="form1" runat="server"> <div> <asp:LinqDataSource ID="LinqDataSource1" runat="server" ContextTypeName="NorthwindDataContext" Select="new (CustomerID, CompanyName, NOTES)" TableName="Customers"> </asp:LinqDataSource> <asp:GridView ID="GridView1" runat="server" AllowPaging="True" AutoGenerateColumns="False" DataSourceID="LinqDataSource1"> <Columns> <asp:BoundField DataField="CustomerID" HeaderText="CustomerID" ReadOnly="True" SortExpression="CustomerID" /> <asp:BoundField DataField="CompanyName" HeaderText="CompanyName" ReadOnly="True" SortExpression="CompanyName" /> <asp:TemplateField HeaderText="NOTES" SortExpression="NOTES"> <EditItemTemplate> <asp:Label ID="Label1" runat="server" Text='<%# Eval("NOTES") %>'></asp:Label> </EditItemTemplate> <ItemTemplate> <asp:Label ID="Label1" runat="server" Text='<%# Eval("NOTES") %>'></asp:Label> </ItemTemplate> </asp:TemplateField> </Columns> </asp:GridView> </div> </form> </body> </html>

很平常的程式碼不是，結(jié)果也很平常：

圖 15：

直到你在第一筆資料的 NOTES 欄位中鍵入下面的文字：

<script>alert('test')</script>

結(jié)果將會有所改變：

圖 16：

歡迎來到 Mass SQL Injection 的世界，Mass SQL Injection 利用了設(shè)計師常忽略了輸出資料時要使用 Html Encode 機制的常識，而進行了非毀滅性的入侵，這種入侵常見於討論區(qū)、部落格或留言版上，他的目的並非毀滅此網(wǎng)站，而只是利用此漏洞來當(dāng)?shù)舸司W(wǎng)站，亦或是將此網(wǎng)站做為跳板，以 Cross-Site Scripting (簡稱為 XSS) 的方式，將使用者所輸入的資料，導(dǎo)向另一網(wǎng)站，而這個網(wǎng)站通常是駭客們所建構(gòu)的，無辜瀏覽此網(wǎng)站的人所輸入的資料就這樣被偷走了。

另一種更狠毒的手法則是利用 Cross-Site Scripting 的方式，在網(wǎng)頁中注入惡意連結(jié)的 Script，透過作業(yè)系統(tǒng)的漏洞如 Windows 的 MS06-014、MS07-004 來入侵使用者的電腦，將網(wǎng)站當(dāng)成跳板是第一步，接著再把瀏覽器當(dāng)成第二跳版，最後入侵使用者的電腦。

當(dāng)然，你可能會說，我常用的是 Bind，不是 Eval 這個函式，那麼我告訴你，這兩者有同樣的問題存在。就算不用到 Eval 或是 Bind，你偶而也會寫成下面這樣子：

.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="InputInjection.aspx.cs" Inherits="InputInjection" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>Untitled Page</title> </head> <body> <form id="form1" runat="server"> <div> <div><%=GetDynamicHtml() %></div> ..........略.......... </div> </form> </body> </html>

.aspx.cs

protected string GetDynamicHtml() { string str = "<b>TEST Injection</b>"; return str; }

想像一下，如果 GetDynamicHtml 函式中的 str 變數(shù)值是由資料庫取得後填入的，你是否有背脊發(fā)涼的感覺了。

如何防止？

防堵 Mass SQL Injection 的方法其實很簡單，除了以 Parameter 或是 LINQ To SQL/LINQ To Entities 來阻檔傳統(tǒng)的 SQL Injection 攻擊外，只要在輸出資料庫資料時，記得用 HtmlEncode 即可：

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="InputInjection.aspx.cs" Inherits="InputInjection" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>Untitled Page</title> </head> <body> <form id="form1" runat="server"> <div> <asp:LinqDataSource ID="LinqDataSource1" runat="server" ContextTypeName="NorthwindDataContext" Select="new (CustomerID, CompanyName, NOTES)" TableName="Customers"> </asp:LinqDataSource> <asp:GridView ID="GridView1" runat="server" AllowPaging="True" AutoGenerateColumns="False" DataSourceID="LinqDataSource1"> <Columns> <asp:BoundField DataField="CustomerID" HeaderText="CustomerID" ReadOnly="True" SortExpression="CustomerID" /> <asp:BoundField DataField="CompanyName" HeaderText="CompanyName" ReadOnly="True" SortExpression="CompanyName" /> <asp:TemplateField HeaderText="NOTES" SortExpression="NOTES"> <EditItemTemplate> <asp:Label ID="Label1" runat="server" Text='<%# Eval("NOTES") %>'></asp:Label> </EditItemTemplate> <ItemTemplate> <asp:Label ID="Label1" runat="server" Text= '<%# Server.HtmlEncode(Eval("NOTES") == null ? "" : Eval("NOTES").ToString()) %>'> </asp:Label> </ItemTemplate> </asp:TemplateField> </Columns> </asp:GridView> </div> </form> </body> </html>

圖 17：

那如果執(zhí)意輸出 HTML 呢？那我只能建議你，在輸出前查查輸出的字串中是否有 script 字樣，並注意 onclick、onkeydown、onblur 等事件及 src tag 的輸出，沒有必要的話，就把所有的事件處理式濾掉，這樣才能讓你逃出 Mass SQL Injection 的攻擊，下面是一個簡單的例子，允許除 script 外的 HTML 輸出。

.aspx

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="InputInjection2.aspx.cs" Inherits="InputInjection2" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title>Untitled Page</title> </head> <body> <form id="form1" runat="server"> <div> <asp:LinqDataSource ID="LinqDataSource1" runat="server" ContextTypeName="NorthwindDataContext" Select="new (CustomerID, CompanyName, NOTES)" TableName="Customers"> </asp:LinqDataSource> <asp:GridView ID="GridView1" runat="server" AllowPaging="True" AutoGenerateColumns="False" DataSourceID="LinqDataSource1"> <Columns> <asp:BoundField DataField="CustomerID" HeaderText="CustomerID" ReadOnly="True" SortExpression="CustomerID" /> <asp:BoundField DataField="CompanyName" HeaderText="CompanyName" ReadOnly="True" SortExpression="CompanyName" /> <asp:TemplateField HeaderText="NOTES" SortExpression="NOTES"> <EditItemTemplate> <asp:Label ID="Label1" runat="server" Text='<%# Eval("NOTES") %>'></asp:Label> </EditItemTemplate> <ItemTemplate> <asp:Label ID="Label1" runat="server" Text='<%# GetSafeHtml(Eval("NOTES")) %>'></asp:Label> </ItemTemplate> </asp:TemplateField> </Columns> </asp:GridView> </div> </form> </body> </html>

.aspx.cs

using System; using System.Collections; using System.Configuration; using System.Data; using System.Linq; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.HtmlControls; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Xml.Linq; public partial class InputInjection2 : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } protected string GetSafeHtml(object o) { if (o != null) { string o2 = (string)o; if (o2.IndexOf("<script",StringComparison.InvariantCultureIgnoreCase) != -1) { while (true) { int index = o2.IndexOf("<script", StringComparison.InvariantCultureIgnoreCase); if (index == -1) break; o2 = o2.Replace(o2.Substring(index, 8), "<!-- "); index = o2.IndexOf("</script>", StringComparison.InvariantCultureIgnoreCase); o2 = o2.Replace(o2.Substring(index, 9), " !-->"); } } return o2; } return string.Empty; }}

當(dāng) NOTES 值為【<b>test</b>】時，輸出結(jié)果如下：

圖 18：

GetSafeHtml 也適用於前例的 GetDynamicHtml 情況下：

<div><%=GetSafeHtml(GetDynamicHtml()) %></div>

關(guān)於 validateRequest

或許你會好奇，ASP.NET 1.1 其之後的版本不是有一個 validateRequest 設(shè)定，只要其值為 True，那麼使用者所輸入的值，將會受到 ASP.NET 的限制 (TextBox、及 URL 後帶的參數(shù)都在此限)，而此值預(yù)設(shè)為 True，意味著如果你沒有特別去修改 mechine.config 或是 web.config 將此值設(shè)為 False，使用者是無法於 TextBox 控件或是 URL 參數(shù)中輸入【<script>alert('test')</script】等字樣的，那也就沒有 Mass SQL Injection 危機了不是嗎？

Web.config

<system.web> ............ <pages buffer="true" validateRequest="true" /> ............ </system.web>

圖 19：

的確，但這樣一來，連【<b>TEST</b>】等輸入也一併被防掉了，在許多討論區(qū)及留言版中，這種輸入是必要的！況且，ASP.NET 1.x 在 validateRequest 的驗證上有著 BUG，若你未更新 ASP.NET 2.0 或是最新的 ASP.NET 1.x Service Pack，那麼 Mass SQL Injection 仍然與你長伴。

那如果用的已是 ASP.NET 2.0，且更新到最新版並將 validateRequest 設(shè)為 Ture 後，是否就可高枕無憂了呢？這我不能保證，因為在BUG未被發(fā)現(xiàn)前，都不叫 BUG！而且在這個 AJAX 盛行的年代，以 XMLHttpRequest 穿透 Validate Request 機制並不是不可能。所以，validateRequest 絕不能做為防止 Mass SQL Injection 的唯一手段，應(yīng)整合 SQL Injection 的所有防範(fàn)手段，至少必須使用 Parameter 或是 LINQ To SQL/LINQ To Entities 來與資料庫溝通，才是正道。

後記

因為網(wǎng)頁是隨手可得，所以成為了駭客們的玩具，本文所提及的僅是關(guān)於 SQL Injection 的手法，其它如 DDoS 等攻擊還是很多，身為網(wǎng)頁設(shè)計師的我們，除了必須細(xì)心之外，還得時常上一些安全性回報網(wǎng)站來擷取新知，對於駭客，我們必須常保初學(xué)者心態(tài)，因為駭客們就是抓住程式設(shè)計師自持身經(jīng)百戰(zhàn)的傲氣，而趁虛而入。

範(fàn)例解說：

檔名	說明
Default.aspx	無設(shè)防之 Login 網(wǎng)頁 (有 SQL Injection 危機)。
Default2.aspx	設(shè)防之 Login 網(wǎng)頁 (使用參數(shù)，無 SQL Injection 危機)。
DefaultWithFilter.aspx	設(shè)防之 Login 網(wǎng)頁，使用過濾法。
QueryStringInjection.aspx	無設(shè)防之 QueryString 網(wǎng)頁(有 SQL Injection 危機)。
InputInjection.aspx	Mass SQL Injection 測試網(wǎng)頁 (已設(shè)防，請自行調(diào)整為不設(shè)防來測試)，使用LINQ To SQL。
InputInjection2.aspx	Mass SQL Injection 測試網(wǎng)頁 2 (已設(shè)防，採用過濾 script 手法) ，使用 LINQ To SQL。
QueryData.aspx	簡單資料查詢頁面 (無設(shè)防，有 SQL Injection 危機)。
QueryData2.aspx	簡單資料查詢頁面 (已設(shè)防，使用參數(shù)，無 SQL Injection 危機)。
QueryData3.aspx	複合查詢頁面 (無設(shè)防，包含無設(shè)防及有設(shè)防之 Stored Procedure 手法)。
QueryData4.aspx	複合查詢頁面 (已設(shè)防，無 SQL Injection 危機)。
LoginWithLINQ.aspx	設(shè)防之 Login 網(wǎng)頁，使用 LINQ To SQL。
QueryData4WithLinq.aspx	設(shè)防之複合查詢頁面，使用 LINQ To SQL。

http://www.microsoft.com/taiwan/msdn/columns/huang_jhong_cheng/LVSS.htm

轉(zhuǎn)載于:https://www.cnblogs.com/yhb199/archive/2008/07/11/1240557.html

總結(jié)

以上是生活随笔為你收集整理的LINQ - 對付 SQL Injection 的 免費補洞策略 （转）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。