SQL注入的其他可能方式？答案

【问题标题】：Other possible ways for SQL injections?SQL注入的其他可能方式？
【发布时间】：2011-12-07 08:59:49
【问题描述】：

我有一个在 SSL 中运行的 ASP.NET 页面，并且检查发生在代码隐藏中。

为了防止sql注入，我做了以下操作：

包含 RegEx 以过滤掉不必要/危险的字符（基本上，它现在只允许 0-9、a-z 和 A-Z）。
使用类似于“SELECT * FROM table WHERE username = @Username...”的查询。
我还添加了帐户锁定功能，因此您只能进行有限的尝试。

在 IBM AppScan 测试漏洞之后，我似乎只修复了 Blind SQL Injection 而没有修复 Authenticated Bypass。

是否有任何我遗漏的东西导致我未能通过漏洞测试？

更新：

...

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 字符内的内容都应该抛出“false”，并导致页面重定向/刷新登录页面。

数据库查询都使用参数化查询，登录正常。那部分没问题。

【问题讨论】：

您的问题主题似乎与您最终提出的实际问题无关。您使用 #2 修复了 SQL 注入；参数化查询。
处理正确，没有危险字符。选项 1 毫无意义，应该通过选项 2 完全缓解。
提供一些关于“经过身份验证的绕过”的信息可能是一个想法。在 Google 中搜索 ibm appscan "authenticated bypass" (google.com/…) 只会产生这个问题。
@spender 哇；这是一些快速索引！
Google 以相当高的速度通过 SO 交流，嗯？

标签： asp.net sql-server-2008 sql-injection

【解决方案1】：

放下你做的第一件事，只使用SqlCommand.Parameters，如下所述：

SQL Injection vs. Lethal Injection / Protection Against SQL Injection

我总是使用多个连接字符串来访问一个数据库，每个都有不同的角色：阅读、写作、执行。当你这样做时，你确保如果攻击在读取操作上成功进行，攻击者除了读取之外不能做其他事情（这仍然很糟糕，但比修改更好）

【讨论】：

@AndrewBarber 我知道。我只是说他做的第一件事没有意义，第二件事会处理一切。
同意； #1 是不必要的（并且是不必要的限制）。
是的，但只要测试通过并且客户想要该功能，我们就无法将其删除...暂时。

【解决方案2】：

显然，代码中有 2 个数据库查询未更新为参数化查询。

参数化查询足以防止 SQL 注入，因此其他步骤/功能有点矫枉过正。

【讨论】：