避免不带参数的SQL注入

Question

我们在这里正在讨论有关在代码中使用参数化的sql查询的另一讨论。我们在讨论中有两个方面：我和其他一些人说我们应该始终使用参数来防止sql注入，而其他人则认为不需要。相反，他们希望在所有字符串中用两个撇号替换单个撇号，以避免sql注入。我们的数据库都运行Sql Server 2005或2008，我们的代码库在.NET Framework 2.0上运行。

让我给您一个简单的C＃示例：

我希望我们使用这个：

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

其他人想这样做时：

string sql = "SELECT * FROM Users WHERE Name=" + SafeDBString(name);

SqlCommand getUser = new SqlCommand(sql, connection);

//... blabla - are we safe now?

SafeDBString函数的定义如下：

string SafeDBString(string inputValue) 

{

    return "'" + inputValue.Replace("'", "''") + "'";

}

现在，只要对查询中的所有字符串值都使用SafeDBString，我们就应该是安全的。对？

使用SafeDBString函数有两个原因。首先，这是自石器时代以来一直采用的方法，其次，由于您看到了在数据库上运行的exact查询，因此调试sql语句更容易。

那就这样 我的问题是，使用SafeDBString函数是否足以避免sql注入攻击，是否真的足够。我一直在尝试查找破坏此安全措施的代码示例，但找不到任何示例。

有没有人可以打破这一点？你会怎么做？

编辑： 总结到目前为止的答复：

还没有人找到在SQL Server 2005或2008上解决SafeDBString的方法。那很好，我想呢？

一些答复指出，使用参数化查询可以提高性能。原因是查询计划可以重复使用。

我们还同意，使用参数化查询可以提供更具可读性的代码，从而更易于维护

此外，始终使用参数比使用各种版本的SafeDBString，字符串到数字的转换以及字符串到日期的转换要容易得多。

使用参数可以实现自动类型转换，这在我们使用日期或十进制数字时特别有用。

最后，不要像JulianR所写的那样尝试自己进行安全保护。数据库供应商在安全性上花费了大量时间和金钱。我们没有办法做得更好，也没有理由应该尝试做他们的工作。

因此，尽管没有人能够破坏SafeDBString函数的简单安全性，但我得到了许多其他很好的论据。谢谢！

Answer 1

我认为正确的答案是：不要试图自己做安全措施。使用任何受信任的行业标准库，您都可以使用它来做您想做的事情，而不是自己尝试做。无论您对安全性做出什么假设，都可能是错误的。尽管您自己的方法看起来很安全（但看起来充其量只是摇摇欲坠），但是您有可能忽略某些东西，而在安全性方面您真的想抓住这个机会吗？使用参数。

Answer 2

该论点是双赢的。如果您确实找到了漏洞，那么您的同事将只更改SafeDBString函数来解决该漏洞，然后要求您再次证明它是不安全的。鉴于参数化查询是无可争议的编程最佳实践，因此举证责任应由它们来说明，为什么他们没有使用既安全又性能更好的方法。如果问题是重写所有旧代码，则简单的折衷办法是在所有新代码中使用参数化查询，并重构旧代码以在处理该代码时使用它们。我的猜测是实际的问题是骄傲和固执，对此您无能为力。