如何打破黑客游戏SQL注入的这一壁垒

SQL注入的攻击是你需要担心的。无论使用什么web编程技术，所有的web框架都需要担心这一点。你需要遵循一些非常基本的规则:

1)在构造动态SQL语句时，必须使用类型安全的参数超重机制。大多数数据API，包括ADO和ADO。NET有这样的支持，它允许您指定所提供参数的确切类型(例如，字符串、整数、日期等。)，它可以确保这些参数被正确地转义/编码，以防止黑客使用它们。务必从头到尾使用这些功能。

例如，对于ADO中的动态SQL。NET中，您可以将上面的语句重写如下以确保安全:

Dim SSN为字符串=请求。查询字符串(“SSN”)

dim cmd As new SqlCommand(" SELECT au _ lname，au _ fname FROM authors WHERE au _ id = @ au _ id ")

dim param = new SQL parameter(" au _ id "，SqlDbType。VarChar)

参数。价值= SSN

cmd。参数. Add(param)

这将防止有人试图偷偷注入另一个SQL表达式(因为ADO。NET知道对au_id的字符串值进行编码)并避免其他数据问题(如数值类型转换不正确等。).请注意，VS 2005内置的TableAdapter/DataSet设计器自动使用这种机制，ASP。NET 2.0数据源控件。

一个常见的误解是，如果使用存储过程或ORM，就可以完全免受SQL注入攻击。这不是真的。您仍然需要确保在向存储过程传递数据时保持谨慎，或者在使用ORM定制查询时保持安全。

2)在部署应用程序之前，一定要进行安全检查。建立正式的安全流程，并在每次更新时检查所有代码。后一点尤为重要。很多时候，我听说开发团队在上线前会做一个详细的安全审查，然后当他们在几周或几个月后做一些小的更新时，他们会跳过安全审查，说“这只是一个小的更新，我们可以稍后再做编码审查”。请始终坚持安全审查。

3)永远不要在数据库中以明文形式存储敏感数据。我个人的看法是，密码应该一直保存在单向)哈希之后，我甚至不喜欢保存在加密之后。默认情况下，ASP。NET 2.0成员API自动为你做到这一点，同时实现了安全盐随机化行为。如果您决定建立自己的会员数据库，我建议您查看我们在此发布的自己的会员提供商的源代码。还要确保你的信用卡和数据库中的其他私人数据是加密的。这样，即使你的数据库被攻破，至少你客户的隐私数据不会被使用。

4)确保您已经编写了一个自动化单元测试，专门验证您的数据访问层和应用程序没有受到SQL注入的攻击。做到这一点是非常重要的，这有助于抓住“只是一个小更新，所以不会有安全问题”的情况所导致的疏忽，并提供额外的安全层，以避免不小心将糟糕的安全缺陷引入到您的应用程序中。

5)锁定你的数据库的安全性，只给访问数据库的web应用功能所需的最低权限。如果web应用程序不需要访问某些表，请确保它不能访问这些表。如果web应用程序只需要只读权限来从您的帐户应付款表生成报表，请确保禁止它插入/更新/删除该表。

6)很多新手在需要防止注入的页面头部使用在线SQL通用反注入系统的程序，防止别人进行手动注入测试。

但是，如果你使用SQL注入分析仪，你可以很容易地跳过反注射系统，并自动分析其注射点。然后只需要几分钟，你的管理员和密码就会被分析出来。

7)对于注射分析仪的预防，笔者通过实验找到了一种简单有效的预防方法。首先，我们需要知道SQL注入分析仪是如何工作的。在操作过程中发现不是针对“admin”管理员，而是针对权限(如flag=1)。这样，无论你的管理员怎么换，都逃不过检测。

第三步:既然逃不过检测，那就做两个，一个是普通管理员，一个是防止注射。为什么这么说？笔者认为，如果找一个最权威的测试来制造假象吸引，而这个盒子里的内容是大于一千字的汉字，就会迫使分析进入满负荷状态甚至耗尽资源而崩溃。让我们修改数据库。

1.修改表结构。修改管理员字段的数据类型，将文本类型改为最大字段255(其实就够了。如果想变大，可以选择备忘录类型)，密码字段也是这样设置的。

4.修改表格。在ID1中设置管理员权限，输入大量汉字(最好100字以上)。

3.将真正的管理员密码放在ID2之后的任何位置(例如，在ID549上)。

因为SQL注入攻击针对的是应用程序开发过程中不严谨的编程，所以对于大多数防火墙来说是“合法”的。问题的解决只能依靠完美的编程。专门针对SQL注入攻击的工具很少，Wpoison有助于用asp和php开发。