其他可能的SQL注入方式？

我有一個運行在SSL中的ASP.NET頁面，檢查發生在代碼隱藏。其他可能的SQL注入方式？

我已經做了以下防止SQL注入：

包括正則表達式來過濾掉不必要的/危險人物（基本上，現在只允許0-9，A-Z，和A-Z）。
使用類似於「SELECT * FROM table WHERE username = @Username ...」的查詢。
我也添加了帳戶鎖定，因此您只有有限的嘗試可用。

在IBM AppScan測試這些漏洞之後，似乎我只修復了Blind SQL Injection而不是Authenticated Bypass。

有沒有什麼我錯過了，導致我無法通過漏洞測試？

UPDATE：

... 

bool bUser = FilterInput(txtUsername.Text); 
bool bPass = FilterInput(txtPassword.Text); 

// check for restricted characters 
if (bUser && bPass) 
    Response.Redirect("Login.aspx"); 
... 

public static bool FilterInput(string text) 
{ 
    // check if string contains only letters and numbers 
    return (Regex.IsMatch(text, @"^[a-zA-Z0-9]+$")); 
}

沒有任何內部的A-ZA-Z0-9字符應該拋出一個 '假'，並會導致頁面重定向/刷新登錄頁面。

數據庫查詢全部使用參數化查詢，登錄工作正常。這部分沒有問題。

來源

2011-12-07 Bahamut

您的問題主題似乎與您結束的實際問題無關。您使用＃2修復了SQL注入;參數化查詢。 –

正確處理，沒有危險字符。選項1沒有意義，應該完全通過選項2來減輕。 – spender

提供「認證旁路」信息可能是一個想法。搜索「ibm appscan」認證繞過「'（http://www.google.com/search?q=ibm+appscan+%22authenticated+bypass%22&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla： en-GB：official＆client = firefox-a）在Google中只產生這個問題。 – spender

顯然有2個DB查詢代碼沒有更新到參數化查詢中。

參數化查詢足以防止SQL注入，因此其他步驟/功能有點過大。

來源

2012-01-03 14:22:05 Bahamut

下降，你沒有，只是用SqlCommand.Parameters如下面解釋的第一件事：

SQL Injection vs. Lethal Injection/Protection Against SQL Injection

我一直使用多個連接字符串才能訪問數據庫和他們每個人都有不同的角色： reading，writing，execution。當你這樣做的時候，你要確保如果攻擊是在讀取操作上成功完成的，攻擊者除了讀取之外不能做其他的事情（這仍然不好，但比修改更好）

來源

2011-12-07 09:13:15 tugberk

OP已經在使用參數化查詢。見項目＃2。 –

@AndrewBarber我知道。我只是說他做的第一件事情沒有意義，第二件事情會照顧到一切。 – tugberk

同意; ＃1是不必要的（並且不必要地限制）。 –

其他可能的SQL注入方式？

回答

相關問題