避免没有参数的 SQL 注入
在这里，我们还将讨论在代码中使用参数化 sql 查询的问题。我们在讨论中有两个方面: 我和其他一些人说，我们应该始终使用参数来防止 sql 注入，而其他人则认为没有必要这样做。相反，他们希望在所有字符串中用两个撇号替换单个撇号，以避免 sql 注入。我们的数据库都在运行 SqlServer2005或2008，而我们的代码库正在运行。NET 框架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 函数有两个原因。首先，这是自石器时代以来一直采用的方法，其次，调试 sql 语句更容易，因为您可以看到在数据库上运行的精确查询。
那么。我的问题是，使用 SafeDBString 函数来避免 sql 注入攻击是否真的足够。我一直在尝试找出破坏这种安全措施的代码的例子，但是我找不到任何这方面的例子。
有人能打破这个吗? 你会怎么做？
编辑: 总结迄今为止的答复:
- 目前还没有人找到在 SqlServer2005或2008上绕过 SafeDBString 的方法。我觉得这很好？
- 一些答复指出，使用参数化查询可以提高性能。原因是可以重用查询计划。
- 我们还同意，使用参数化查询可以提供更易于维护的可读代码
- 此外，总是使用参数比使用各种版本的 SafeDBString、字符串到数字的转换和字符串到日期的转换更容易。
- 使用参数可以自动进行类型转换，这在处理日期或十进制数时特别有用。
- 最后，朱利安写的 不要试图自己做安全。数据库供应商在安全性方面花费了大量的时间和金钱。我们没有办法做得更好，也没有理由去做他们的工作。
因此，虽然没有人能够破坏 SafeDBString 函数的简单安全性，但我得到了许多其他好的参数。谢谢！
最佳答案