SQL注入防御:用三种策略应对SQL注入攻击[2]
* Microsoft安全部门(The Microsoft Security Development Lifecycle SDL)对SQL注入的防御进行了一些指导 简单来说有三种策略来应对SQL注入攻击 使用SQL参数查询 使用存储过程 使用SQL仅执行(execute only)许可 同时 编写安全的代码(第二版)也指导了如何防御此类攻击 * 减轻SQL注入 使用参数查询(第一部分和第二部分) 使用参数化查询的好处是它将执行的代码(例如SELECT语句)和数据(由程序使用者提供的动态信息)分开 该途径防御了通过用户传递来执行的恶意语句 在经典ASP代码中过滤SQL注入(或者黑名单中的字符) 我们将如下的工作认为是实际中临时性的解决方案 因为它治标不治本 (例如 代码仍然是有漏洞的 他仍然可能被绕过过滤机制而被访问到) 如果你仍然不了解从哪里开始 所有使用特定ASP代码访问数据库 尤其是使用由用户提供的数据的代码应当首先被检测 lishixinzhi/Article/program/SQL/201311/16221
SQL注入攻击与防范
关于SQL注入攻击与防范 随着网络的普及,关系数据库的广泛应用,网络安全越来越重要。下面是我为大家搜索整理了关于SQL注入攻击与防范,欢迎参考阅读,希望对大家有所帮助。想了解更多相关信息请持续关注我们应届毕业生培训网! 一、 SQL注入攻击 简言之,SQL注入是应用程序开发人员未预期地把SQL代码传入到应用程序的过程。它由于应用程序的糟糕设计而成为可能,并且只有那些直接使用用户提供的值构建SQL语句的应用程序才会受影响。 例如:用户输入客户ID后,GridView显示客户的全部行记录。在一个更加真实的案例中,用户还要输入密码之类的验证信息,或者根据前面的登录页面得到用户ID,可能还会有一些用户输入关键信息的文本框,如订单的日期范围或产品名称。问题在于命令是如何被执行的。在这个示例中,SQL语句通过字符串构造技术动态创建。文本框txtID的值被直接复制到字符串中。下面是代码: 在这个示例中,攻击者可以篡改SQL语句。通常,攻击的第一个目标是得到错误信息。如果错误没有被恰当处理,底层的信息就会暴露给攻击者。这些信息可用于进一步攻击。 例如,想象一下在文本一下在文本框中输入下面的字符串会发生什么? ALFKI'OR '1'='1 再看看因此生成的完整SQL语句: 这条语句将返回所有的订单记录,即便那些订单不是由ALFDI创建,因为对每一行而言而有信1=1总是true。这样产生的后果是没有显示当前用户特定信息,却向攻击者显示了全部资料,如果屏幕上显示的是敏感信息,如社会保险号,生日或信用卡资料,就会带来严重的问题。事实上,这些简单的SQL注入往往是困扰那些大型电子商务公司的麻烦。一般而言,攻击点不在于文本框而在于查询字符串(可被用于向数据库传送值,如列表页向详细信息页面传送唯一标识符)。 还可以进行更复杂的攻击。例如,攻击者可以使用两个连接号(--)注释掉SQL语句的剩余部分。这样的攻击只限于SQL Server,不过对于其他类型的数据库也有等效的办法,如MySql使用(#)号,Oracle使用(;)号。另外攻击者还可以执行含有任意SQL语句的批处理命令。对于SQL Server提供程序,攻击者只需在新命令前加上分号(;)。攻击者可以采用这样的方式删除其他表的内容,甚至调用SQL Server的系统存储过程xp_cmdshell在命令执行任意的程序。 下面是攻击者在文本框中输入的,它的攻击目标是删除Customers表的全部行。 LUNCHUN’;DELETE*FROM Customers-- 二、防范 如何预防SQL注入攻击呢?需要记住几点。首先,使用TextBox.MaxLength属性防止用户输入过长的字符是一个好办法。因为它们不够长,也就减少了贴入大量脚本的可能性。其次,要使用ASP.NET验证控件锁定错误的数据(如文本、空格、数值中的特殊字符)。另外,要限制错误信息给出的提示。捕获到数据库异常时,只显示一些通用的信息(如“数据源错误”)而不是显示Exception.Message属性中的信息,它可能暴露了系统攻击点。 更为重要的是,一定要小心去除特殊字符。比如,可以将单引号替换为两个单引号,这样它们就不会和SQL语句的分隔符混淆: string ID=txtID.Text().Replace(“’”,”’’”); 当然,如果文本确实需要包含单引号,这样做就引入了其他麻烦。另外,某些SQL注入攻击还是可行的。替换单引号可以防止用户提前结束一个字符串,然而,如果动态构建含有数值的SQL语句,SQL注入攻击又有发挥的空间了。这个漏洞常被(这是很危险的)忽视。更好的解决办法是使用参数化的命令或使用存储过程执行转义以防止SQL注入攻击。 另一个好建议是限制用于访问数据库的账号的权限。这样该账号将没有权限访问其他数据库或执行扩展的存储过程。不过这样并不能解决SQL脚本注入的问题,因为用于连接数据库的进程几乎总是需要比任意单个用户更大的权限。通过限制权限,可以预防删除表的攻击,但不能阻止攻击者偷看别人的.信息 三、POST注入攻击 精明的用户可能会知道还有另外一个Web控件攻击的潜在途径。虽然参数化的命令防止了SQL注入攻击,但它们不能阻止攻击者向回发到服务器的数据添加恶意的值。如果不检查这些值,就使得攻击者可以提交本来不可能存在的控件值。 例如,假设你有一个显示当前用户订单的列表。狡诈的攻击者可能保存该页面的一个本地副本,修改HTML内容向列表添加更多的项目,然后选择某个“假”的项目。如果攻击成功,攻击者就能够看到其他用户订单,这显然是一个问题。幸好,ASP.NET使用一个很少被提及的叫做“事件验证”的特性来防止这种攻击。事件验证检查回发到服务器的数据并验证其中值的合法性。例如,如果回发的数据表明用户选择了一个没有意义的数据(因为它在控件中并不存在),ASP.NET就产生一个错误并停止处理。可以在Page指令中设置EnableEventValidation特性为false来禁用事件验证。创建使用客户端脚本动态改变内容的页面时,需要执行这一步。不过,此时在使用这些值之前要注意检查潜在的POST注入攻击。 ;