如果你不熟悉SQL注入攻擊和它們對你的應用軟體的潛在危險，請參考MSDN的文章 “SQLInjection” (http://msdn2.microsoft.com/en-us/library/ms161953.aspx)。

僅僅依賴儲存過程而無法執行一個深入防禦的問題在於你真的只指望儲存過程開發者為你提供安全。類似於下面SQLServer程式碼用來鑑別一個使用者的儲存過程非常常見：

ALTER PROCEDURE LoginUser
(
@UserID [nvarchar](12),
@Password [nvarchar](12)
)
AS
SELECT * FROM Users WHERE UserID = @UserID AND Password = @Password
RETURN

這個儲存過程看起來非常安全，但是考慮一下這個：

ALTER PROCEDURE LoginUser
(
@UserID [nvarchar](12),
@Password [nvarchar](12)
)
AS
EXECUTE (‘SELECT * FROM Users WHERE UserID = ‘’’ + @UserID + ‘’’
AND Password = ‘’’ + @Password + ‘’’’)
RETURN

通過建立一個特別的SQL宣告，而且把它放到儲存過程程式碼的EXECUTE函式中，我們真的可以生成一個儲存過程SQL注入。當你使用控制程式碼來寫儲存過程的時候，這個更加容易，它在Microsoft SQL Server 2005中以新的方式支援：

[Microsoft.SqlServer.Server.SqlProcedure]
public static void LoginUser(SqlString userId, SqlString password)
{
using (SqlConnection conn = new SqlConnection(“context connection=true”))
{
SqlCommand selectUserCommand = new SqlCommand();
selectUserCommand.CommandText = “SELECT * FROM Users WHERE UserID = ‘”
+ userId.Value + “’ AND Password = ‘” + password.Value + “’”;
selectUserCommand.Connection = conn;

conn.Open();
SqlDataReader reader = selectUserCommand.ExecuteReader();
SqlContext.Pipe.Send(reader);
reader.Close();
conn.Close();
}
}

甚至就算你是寫儲存過程的那個人，你通常不能確定其他人會在你後面在應用軟體配置以後改變程式碼。關於Web應用這尤其可能，而這也是為什麼一個需要一個深入防禦策略。

明顯地，這個問題的解決是採用一個深入防禦策略。你應該繼續使用儲存過程和引數化任何有必要的查詢，但是你也應該設法建立你的深入防禦策略來保證傳給這些儲存過程的的引數和查詢的驗證。在我們上面的使用者鑑定例子中，“bobsmith”可能是一個有效的使用者ID，但是“SELECT * FROM tblCreditCards”或許不是。對於驗證使用者輸入使用你的深入防禦策略的一個好的方式是對它採用規範化的表達規則。你能使用在System.Web.UI.WebControls名字空間中的RegularExpressionValidator控制尋找來驗證Web表格資料，而且你可以使用在theSystem.Text.RegularExpressions 名字空間中Regex類尋找來驗證任何類別的文字資料。這裡有一個Web表格的例子，在把使用者輸入傳遞給資料庫前對它進行驗證。

protected void Page_Load(object sender, EventArgs e)
{
if (Page.IsPostBack)
{
// We allow only alphanumeric input
Regex allowRegex = new Regex(“^[a-zA-Z0-9]*$”);
if ((!allowRegex.IsMatch(textBoxUserId.Text))
|| (!allowRegex.IsMatch(textBoxPassword.Text)))
{
labelErrorMessage.Text = “Invalid user ID or password.”;
return;
}
else
{
// Call the login stored procedure
…
}
}
}

一個更加徹底的深入防禦策略是使用一個允許輸入聯合模式(也被認為是“優選名單”)和拒絕輸入模式(或者稱為”黑名單”)。使用者的輸入必須匹配優選名單模式(或者說至少一個優選名單模式，如果不多於一個的話)而且不和黑名單模式匹配(或者說任何黑名單模式)。如果在你的允許輸入表中允許類似省略號這樣的非字元輸入，在深度防禦策略中，你應該明確的使用黑名單模式。

// We allow alpha characters, spaces, and apostrophes as input
Regex allowRegex = new Regex(@“^[a-zA-Z\s\’]*$”);
// But we disallow common SQL functions
Regex disallowRegex = new Regex(“(union|select|drop|delete)”);
if ((!allowRegex.IsMatch(textBoxLastName.Text)) || (disallowRegex.IsMatch(textBoxLastName.Text)))
{
labelErrorMessage.Text = “Invalid name.”;
return;
}

最後，我們必須論及加入損害控制到你的深入防禦策略。如果一個黑客真的找到了一個對你的資料庫執行SQL命令的途徑，他可能會造成什麼樣的損害呢？如果你的應用程式作為一個管理員使用者連線到資料庫，象Microsoft SQL Server的”sa”使用者，損害甚至會很嚴重。他不僅僅能看錶中的資料，他也能增加他自己的新資料或者改變已經存在資料的值。設想一個線上購物站點，所有的商品專案價格標成低於一個美分。他能夠增加新的使用者或者刪除已經存在使用者。他能刪除行，表或者甚至整個資料庫。你能通過應用最少許可權原則到你的深入防禦策略減輕這個風險：使你的應用軟體作為一個只有足夠執行必需動作的許可，而沒有其它更多的許可。如果你的應用程式只是從一個數據庫中讀資料，去掉資料庫使用者插入，更新和刪除的許可。如果應用程式只需要對一個產品目錄資料庫進行存取(舉例來說)，確保使用者不能存取定購歷史資料庫。永遠不要指定”sa”或者任何管理員使用者作為資料庫使用者。

通過採用一個深入防禦策略，你可以避免大一個SQL注入攻擊導致你應用程式的多數或者所有的損害。就很多原因包括提高安全來說，使用儲存過程是一個很好的主意，但是一定不要依賴它們提供你所有的安全。總是驗證使用者輸入，而且採用最少許可權原則來減小一個成功的攻擊能引起的損害。

關於作者

Bryan Sullivan是SPI Dynamics 一個Web應用軟體安全產品公司的開發經理。Bryan管理DevInspect 和 QAInspect Web 安全產品，這些產品幫助程式設計師在整個開發和測試過程中維護應用程式的安全。他在Georgia Tech獲得本科學位，而且有11年資訊科技產業工作經驗。他也對AVDL有所貢獻，這已經成為應用軟體安全行業的一個標誌。