我們?cè)谶@里正在討論有關(guān)在代碼中使用參數(shù)化的sql查詢的另一討論。我們?cè)谟懻撝杏袃蓚€(gè)方面：我和其他一些人說我們應(yīng)該始終使用參數(shù)來防止sql注入，而其他人則認(rèn)為不需要。相反，他們希望在所有字符串中用兩個(gè)撇號(hào)替換單個(gè)撇號(hào)，以避免sql注入。我們的數(shù)據(jù)庫都運(yùn)行Sql Server 2005或2008，我們的代碼庫在.NET Framework 2.0上運(yùn)行。讓我給您一個(gè)簡(jiǎn)單的C＃示例：我希望我們使用這個(gè)：string sql = "SELECT * FROM Users WHERE Name=@name";SqlCommand getUser = new SqlCommand(sql, connection);getUser.Parameters.AddWithValue("@name", userName);//... blabla - do something here, this is safe其他人想這樣做時(shí)：string sql = "SELECT * FROM Users WHERE Name=" + SafeDBString(name);SqlCommand getUser = new SqlCommand(sql, connection);//... blabla - are we safe now?SafeDBString函數(shù)的定義如下：string SafeDBString(string inputValue) {    return "'" + inputValue.Replace("'", "''") + "'";}現(xiàn)在，只要對(duì)查詢中的所有字符串值都使用SafeDBString，我們就應(yīng)該是安全的。對(duì)？使用SafeDBString函數(shù)有兩個(gè)原因。首先，這是自石器時(shí)代以來一直采用的方法，其次，由于您看到了在數(shù)據(jù)庫上運(yùn)行的exact查詢，因此調(diào)試sql語句更容易。那就這樣 我的問題是，使用SafeDBString函數(shù)是否足以避免sql注入攻擊，是否真的足夠。我一直在嘗試查找破壞此安全措施的代碼示例，但找不到任何示例。有沒有人可以打破這一點(diǎn)？你會(huì)怎么做？編輯： 總結(jié)到目前為止的答復(fù)：還沒有人找到在SQL Server 2005或2008上解決SafeDBString的方法。那很好，我想呢？一些答復(fù)指出，使用參數(shù)化查詢可以提高性能。原因是查詢計(jì)劃可以重復(fù)使用。我們還同意，使用參數(shù)化查詢可以提供更具可讀性的代碼，從而更易于維護(hù)此外，始終使用參數(shù)比使用各種版本的SafeDBString，字符串到數(shù)字的轉(zhuǎn)換以及字符串到日期的轉(zhuǎn)換要容易得多。使用參數(shù)可以實(shí)現(xiàn)自動(dòng)類型轉(zhuǎn)換，這在我們使用日期或十進(jìn)制數(shù)字時(shí)特別有用。最后，不要像JulianR所寫的那樣嘗試自己進(jìn)行安全保護(hù)。數(shù)據(jù)庫供應(yīng)商在安全性上花費(fèi)了大量時(shí)間和金錢。我們沒有辦法做得更好，也沒有理由應(yīng)該嘗試做他們的工作。因此，盡管沒有人能夠破壞SafeDBString函數(shù)的簡(jiǎn)單安全性，但我得到了許多其他很好的論據(jù)。謝謝！