避免不带参数的SQL注入
在我们的代码中,我们正在进行另一个关于使用参数化SQL查询的讨论。 我们有两方面的讨论:我和其他一些人说,我们应该总是使用参数来防止sql注入和其他人认为这是不必要的。 相反,他们希望用所有字符串中的两个撇号替换单撇号以避免sql注入。 我们的数据库都运行Sql Server 2005或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函数。 首先,它是从石器时代开始已经完成的方式,其次,由于您看到在数据库上运行的excact查询,因此更容易调试sql语句。
那么。 我的问题是,是否真的足够使用SafeDBString函数来避免SQL注入攻击。 我一直在试图找到打破此安全措施的代码示例,但我找不到任何示例。
有没有人可以打破这个? 你会怎么做?
编辑:总结到目前为止的回复:
所以,虽然没有人能够打破SafeDBString函数的简单安全性,但我还是得到了很多其他好的论点。 谢谢!
我认为正确的答案是:
不要试图自己做安全。 使用任何值得信赖的行业标准库可用于您正在尝试做的事情,而不是试图自己做。 无论你对安全做出什么假设,都可能是不正确的。 就像你自己的方法看起来一样安全(而且看起来好像不稳定),那么你有可能忽略某些东西,并且在安全方面你真的想要抓住这个机会吗?
使用参数。
然后有人去使用“而不是”。参数是,IMO,唯一安全的方法。
它还避免了许多日期/数字的国际化问题; 什么日期是01/02/03? 多少是123456? 你的服务器(app-server和db-server)是否一致?
如果风险因素不能令人信服,那么表现如何? 如果使用参数,RDBMS可以重新使用查询计划,从而提高性能。 它不能只用字符串来完成。
这个说法是不成功的。 如果您确实设法找到漏洞,那么您的同事将只更改SafeDBString函数来解释它,然后要求您再次证明它不安全。
鉴于参数化查询是无可争议的编程最佳实践,举证责任应该放在他们身上,以说明为什么他们没有使用既安全又更好的方法。
如果问题在于重写所有遗留代码,那么简单的妥协就是在所有新代码中使用参数化查询,并在处理代码时重构旧代码以使用它们。
我的猜测是真正的问题是骄傲和固执,对此你没有什么可以做的。
链接地址: http://www.djcxy.com/p/93971.html上一篇: Avoiding SQL injection without parameters
下一篇: How to get the selected value from dropdown list and past it to sql query