如何避免我的ASP.NET应用程序中的SQL注入攻击?

我需要避免在ASP.NET应用程序中容易受到SQL注入的攻击。 我怎么能做到这一点?

即使你的问题是非常通用的,总是有一些规则:

  • 使用参数化查询( SqlCommandSqlParameter )并将用户input放入参数中。
  • 不要从未经检查的用户input中构buildSQLstring。
  • 不要以为你可以build立一个消毒程序,可以检查用户input的各种错误。 边缘情况很容易被遗忘。 检查数字input可能很简单,可以让你安全起见,但是对于stringinput只是使用参数。
  • 检查二级漏洞 – 如果这些值由用户input组成,请不要从SQL表值中构buildSQL查询string。
  • 使用存储过程来封装数据库操作。

使用“ 准备好的语句” (链接到在“为产品添加节点”部分使用准备语句的ASP.NET教程)。 这就是它的全部。

那么,或者使用一个ORM,像Linq到SQL或NHibernate ,它们在内部使用预准备语句。

使用参数! 这真的很简单:-)

像这样创build你的查询(对于使用C#的MS Sql服务器):

 SqlCommand getPersons = new SqlCommand("SELECT * FROM Table WHERE Name = @Name", conn); 

这里@Name是你想避免sql注入的参数,而conn是一个SqlConnection对象。 然后添加参数值,您可以执行以下操作:

 getPersons.Parameters.AddWithValue("@Name", theName); 

这里的名字是一个包含你正在search的名字的variables。

现在应该不可能对该查询执行任何sql注入。

既然这是简单的,没有理由不使用参数。

永远不要相信用户input – 使用validation控件,正则expression式,代码等validation所有文本框条目

切勿使用dynamicSQL – 使用参数化的SQL或存储过程

切勿使用pipe理员级别帐户连接到数据库 – 使用有限的访问帐户连接到数据库

不要以明文存储秘密 – encryption或散列密码和其他敏感数据; 你还应该encryption连接string

例外情况应该泄漏最less的信息 – 不要在错误信息中透露太多信息; 使用customErrors在未处理错误的情况下显示最less的信息; 将debugging设置为false

MSDN上有用的链接停止SQL注入

发生SQL注入是因为对数据库的查询正在实时构build,例如:

 SELECT * From Table1 WHERE " + UserInput 

UserInput可能是恶意的,并且包含您不打算的其他语句。

为了避免它,你需要避免连接你的查询。

您可以通过使用参数化查询来完成此操作 – 检查DBCommand对象是否具有特定的DB风格。

使用参数化查询和/或存储过程,并通过SQL参数parsing参数。 切勿通过连接string来生成SQL代码。 也做一些关于SQL注入和关于编写安全代码的阅读,因为防止SQL注入只是安全性的一小部分。 还有很多(比如XSS – Cross Site Scripting)。 如果一个黑客想要破坏你的网站/应用程序,他会寻找更多的只有SQL注入。

斯科特·格思里(Scott Guthrie)早就发表了一篇不错的文章 。 在这里,他提供了5条保护自己的build议:

  1. 不要使用types安全参数编码机制来构造dynamicSQL语句。 […]

  2. 始终在应用程序投入生产之前始终对应用程序进行安全审查,并build立正式的安全过程,以随时更新所有代码。 […]

  3. 切勿将敏感数据以明文存储在数据库中。 […]

  4. 确保您编写自动化unit testing,专门validation数据访问层和应用程序是否针对SQL注入攻击。 […]

  5. locking您的数据库只允许访问它的Web应用程序需要它的最小权限集。 […]

他做了一个体面的工作,解释为什么这些是重要的,并链接到其他几个资源以及…

永远不要信任用户input,总是validation它,并使用sql参数。 应该有足够的基础来防止SQL注入。

希望这将有助于:

http://www.codersbarn.com/post/2008/11/01/ASPNET-Data-Input-Validation.aspx

简短的答案是使用参数化查询。

安东尼:-) http://www.codersbarn.com

始终只使用参数化查询。

本书“构build安全ASP.NET应用程序”指南中有关于此主题的一节 。

正如其他人所说,不要连接用户input来创builddynamic的sql语句; 在使用dynamicSQL时总是使用参数化的SQL。 但是我会指出,这个规则也适用于在存储过程中创builddynamicsql 。 这个事实是人们经常忽略的。 他们认为他们是安全的,因为他们“使用存储过程”。

使用XSS Secured UrlEncode使用Microsoft.Security.Application.AntiXss.UrlEncode和SQL注入将无法正常工作。 或者你可以使用ASP.NET – JSON – 序列化和反序列化

也可以使用Macfee Fre Tool中的SiteDigger来testing您的应用程序。

几乎没有从这里

.NET安全工具包v1.0 .NETMon v1.0 Validator.NET v1.0

大家都说“使用参数”。 如果不是那么困难的话,我们不得不说得更less。

使用QueryFirst 。 连接的诱惑被删除了,正确的方法成为最简单的方法。 只需在SQL中input@myParam创build一个参数,剩下的工具就完成了。

免责声明:我写了QueryFirst

了解到底是什么SQL注入,然后从不写任何易受攻击的东西。

尝试使用存储过程,并validation您的数据input。 不要使用任何直接的SQL,如INSERT INTO …