這足以保護再次SQL注入？

我試圖使用MS SQL 2008 R2（Express Edition）來保護一個較舊的經典asp網站（擁有大約1,000（.asp）頁面）。這足以保護再次SQL注入？

我發現了一個關於如何參數化查詢的代碼（參見下文），代碼看起來是我理解和使用的所有需要更改的頁面上最簡單的代碼。

我的問題是：如果我要轉換所有的MS SQL查詢（這將看起來像下面的代碼）是否足以防止MS SQL注入攻擊？還是有更多我需要添加/更改？

感謝您的幫助......

這裏是代碼：

set objCommand = Server.CreateObject("ADODB.Command") 
    strSql = "SELECT * FROM users WHERE username=? AND password=?" 
    ... 
    cmd1.Parameters(0) = Request.Form("login") 
    cmd1.Parameters(1) = Request.Form("password") 
    ...

來源

2012-08-01 compcobalt

它應該儘可能地注意SQL注入。我仍然是存儲過程和命名參數的粉絲。 SP提供了一個清晰定義的接口，並且作爲數據庫對象可以應用安全性。明確定義參數及其數據類型有助於確定界面。參數的默認值可以在SP中提供並進行驗證。 – HABO 2012-08-01 21:52:59

@HABO會提供kd7提供的代碼（請參閱下面的答案＃2）解決所有問題還是仍然存在可能導致問題的漏洞？（對不起，我知道這可能是一個noob問題，但我只想了解我必須做什麼才能使這個安全的網絡應用程序，並開始chaning 1000+頁）非常感謝... – compcobalt 2012-08-02 16:59:42

它將工作一個簡單的網站，但在大型環境中成爲維護頭痛。部分問題是遍佈各處的SQL片段。什麼應該是次要的數據庫更改，更新後的SP將成爲通過包含SQL的所有地點進行搜索，或者實時構建它。 SP的執行計劃會在每次調用時保留並重用（除非您指定'WITH RECOMPILE'）。這通常有助於表現。 SP可以提供訪問者無法訪問的數據的有限訪問權限，這對於具有多個應用程序的大型項目很重要。 – HABO 2012-08-02 17:12:34

它已經有一段時間我見過的舊ADODB命令的語法，但我想你會想是這樣的：

set objCommand = Server.CreateObject("ADODB.Command") 
strSql = "Select * From users where [email protected] and [email protected]" 
objCommand.Parameters.Append.CreateParameter 
     ("@username", adVarChar, adParamInput, 50, Request.Form("login")) 
objCommand.Parameters.Append.CreateParameter 
     ("@password", adVarChar, adParamInput, 50, Request.Form("password"))

與往常一樣，不要創建沒有類型安全參數編碼的動態sql語句，我想即使是老派的ADO也可以通過CreateParameter提供。

來源

2012-08-01 21:54:25 kd7

非常感謝上面的例子，它真的幫助我更好地理解如何做到這一點。我在這是一個完全noob，但我想了解它是如何工作的，所以我確保我做的一切都正確。 – compcobalt 2012-08-02 13:26:58

是的，你在你的問題中提供的代碼被固定以防止SQL注入。

但是，as noted in this article on mitigating Sql Injection，您的代碼將有「性能問題，因爲在執行查詢之前，ADODB將不得不往返SQL來確定參數類型。」

您可以使用您的代碼顯式指定參數類型解決此CreateParameter

來源

2012-08-01 21:54:08

這足以保護再次SQL注入？

回答

相關問題