SQL注入攻防入门详解 [图文并茂] 附示例下载

=============安全性篇目录============== 毕业开始从事winfrm到今年转到 web ，在码农届已经足足混了快接近3年了，但是对安全方面的知识依旧薄弱，事实上是没机会接触相关开发……必须的各种借口。这几天把sql注入的相关知识整理了下，希望大家多多提意见。 （对于sql注入的攻防，我只用过简单拼接字符串的注入及参数化查询，可以说没什么好经验，为避免后知后觉的犯下大错，专门查看大量前辈们的心得，这方面的资料颇多，将其精简出自己觉得重要的，就成了该文） 下面的程序方案是采用 ASP.NET + MSSQL，其他技术在设置上会有少许不同。 示例程序下载：SQL注入攻防入门详解_示例 什么是SQL注入（SQL Injection） 所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。 尝尝SQL注入 1. 一个简单的登录页面 关键代码：（详细见下载的示例代码）

方法中userName和 password 是没有经过任何处理，直接拿前端传入的数据，这样拼接的SQL会存在注入漏洞。（帐户：admin 123456） 1) 输入正常数据，效果如图：

合并的SQL为： SELECT COUNT(*) FROM Login WHERE UserName=\’admin\’ AND Password=\’123456\’ 2) 输入注入数据： 如图，即用户名为：用户名：admin’—，密码可随便输入

合并的SQL为： SELECT COUNT(*) FROM Login WHERE UserName=\’admin\’– Password=\’123\’ 因为UserName值中输入了“–”注释符，后面语句被省略而登录成功。（常常的手法：前面加上\’; \’ (分号，用于结束前一条语句)，后边加上\’–\’ (用于注释后边的语句)） 2. 上面是最简单的一种SQL注入，常见的注入语句还有：

b) 更高级的攻击，将上面的注入SQL进行“HEX编码”，从而避免程序的关键字检查、脚本转义等，通过EXEC执行

c) 批次删除数据库被注入的脚本

d) 我如何得到“HEX编码”？ 开始不知道HEX是什么东西，后面查了是“十六进制”，网上已经给出两种转换方式：（注意转换的时候不要加入十六进制的标示符 ’0x’ ） Ø 在线转换 （TRANSLATOR, BINARY），进入…… Ø C#版的转换，进入…… 防止SQL注入 1. 数据库权限控制，只给访问数据库的web应用功能所需的最低权限帐户。 如MSSQL中一共存在8种权限：sysadmin, dbcreator, diskadmin, processadmin, serveradmin, setupadmin, securityadmin, bulkadmin。 2. 自定义错误信息，首先我们要屏蔽服务器的详细错误信息传到客户端。 在 ASP.NET 中，可通过web.config配置文件的<customErrors>节点设置：

设置为<customErrors mode="Off">：

3. 把危险的和不必要的存储过程删除 xp_：扩展存储过程的前缀，SQL注入攻击得手之后，攻击者往往会通过执行xp_cmdshell之类的扩展存储过程，获取系统信息，甚至控制、破坏系统。

4. 非参数化SQL与参数化SQL 1) 非参数化（动态拼接SQL） a) 检查客户端脚本：若使用.net，直接用System.Net.WebUtility.HtmlEncode(string)将输入值中包含的《HTML特殊转义字符》转换掉。 b) 类型检查：对接收数据有明确要求的，在方法内进行类型验证。如数值型用int.TryParse()，日期型用DateTime.TryParse() ，只能用英文或数字等。 c) 长度验证：要进行必要的注入，其语句也是有长度的。所以如果你原本只允许输入10字符，那么严格控制10个字符长度，一些注入语句就没办法进行。 d) 使用枚举：如果只有有限的几个值，就用枚举。 e) 关键字过滤：这个门槛比较高，因为各个数据库存在关键字，内置函数的差异，所以对编写此函数的功底要求较高。如公司或个人有积累一个比较好的通用过滤函数还请留言分享下，学习学习，谢谢！ 这边提供一个关键字过滤参考方案(MSSQL)：

优点：写法相对简单，网络传输量相对参数化拼接SQL小 缺点： a) 对于关键字过滤，常常“顾此失彼”，如漏掉关键字，系统函数，对于HEX编码的SQL语句没办法识别等等，并且需要针对各个数据库封装函数。 b) 无法满足需求：用户本来就想发表包含这些过滤字符的数据。 c) 执行拼接的SQL浪费大量缓存空间来存储只用一次的查询计划。服务器的物理内存有限，SQLServer的缓存空间也有限。有限的空间应该被充分利用。 2) 参数化查询（Parameterized Query） a) 检查客户端脚本，类型检查，长度验证，使用枚举，明确的关键字过滤这些操作也是需要的。他们能尽早检查出数据的有效性。 b) 参数化查询原理：在使用参数化查询的情况下，数据库服务器不会将参数的内容视为SQL指令的一部份来处理，而是在数据库完成 SQL 指令的编译后，才套用参数运行，因此就算参数中含有具有损的指令，也不会被数据库所运行。 c) 所以在实际开发中，入口处的安全检查是必要的，参数化查询应作为最后一道安全防线。 优点： Ø 防止SQL注入(使单引号、分号、注释符、xp_扩展函数、拼接SQL语句、EXEC、SELECT、UPDATE、DELETE等SQL指令无效化) Ø 参数化查询能强制执行类型和长度检查。 Ø 在MSSQL中生成并重用查询计划，从而提高查询效率（执行一条SQL语句，其生成查询计划将消耗大于50%的时间） 缺点： Ø 不是所有数据库都支持参数化查询。目前Access、SQL Server、MySQL、SQLite、Oracle等常用数据库支持参数化查询。 疑问：参数化如何“批量更新”数据库。 a) 通过在参数名上增加一个计数来区分开多个参数化语句拼接中的同名参数。 EG：

b) 通过MSSQL 2008的新特性：表值参数，将C#中的整个表当参数传递给存储过程，由SQL做逻辑处理。注意C#中参数设置parameter.SqlDbType = System.Data.SqlDbType.Structured; 详细请查看…… 疑虑：有部份的开发人员可能会认为使用参数化查询，会让程序更不好维护，或者在实现部份功能上会非常不便，然而，使用参数化查询造成的额外开发成本，通常都远低于因为SQL注入攻击漏洞被发现而遭受攻击，所造成的重大损失。 另外：想验证重用查询计划的同学，可以使用下面两段辅助语法

3) 参数化查询示例

效果如图：

参数化关键代码：

5. 存储过程 存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。 优点： a) 安全性高，防止SQL注入并且可设定只有某些用户才能使用指定存储过程。 b) 在创建时进行预编译，后续的调用不需再重新编译。 c) 可以降低网络的通信量。存储过程方案中用传递存储过程名来代替SQL语句。 缺点： a) 非应用程序内联代码，调式麻烦。 b) 修改麻烦，因为要不断的切换开发工具。（不过也有好的一面，一些易变动的规则做到存储过程中，如变动就不需要重新编译应用程序） c) 如果在一个程序系统中大量的使用存储过程，到程序交付使用的时候随着用户需求的增加会导致数据结构的变化，接着就是系统的相关问题了，最后如果用户想维护该系统可以说是很难很难（eg：没有VS的查询功能）。 演示请下载示例程序，关键代码为：

如果在存储过程中SQL语法很复杂需要根据逻辑进行拼接，这时是否还具有放注入的功能？ 答：MSSQL中可以通过 EXEC 和sp_executesql动态执行拼接的sql语句，但sp_executesql支持替换 Transact-SQL 字符串中指定的任何参数值， EXECUTE 语句不支持。所以只有使用sp_executesql方式才能启到参数化防止SQL注入。 关键代码：（详细见示例） a) sp_executesql

b) EXECUTE（注意sql中拼接字符，对于字符参数需要额外包一层单引号，需要输入两个单引号来标识sql中的一个单引号）

注入截图如下：

6. 专业的SQL注入工具及防毒软件 情景1 A：“丫的，又中毒了……” B：“我看看，你这不是裸机在跑吗？” 电脑上至少也要装一款杀毒软件或木马扫描软件，这样可以避免一些常见的侵入。比如开篇提到的SQL创建windows帐户，就会立马报出警报。 情景2 A：“终于把网站做好了，太完美了，已经检查过没有漏洞了！” A：“网站怎么被黑了，怎么入侵的？？？” 公司或个人有财力的话还是有必要购买一款专业SQL注入工具来验证下自己的网站，这些工具毕竟是专业的安全人员研发，在安全领域都有自己的独到之处。SQL注入工具介绍：10个SQL注入工具 7. 额外小知识：LIKE中的通配符 尽管这个不属于SQL注入，但是其被恶意使用的方式是和SQL注入类似的。

在模糊查询LIKE中，对于输入数据中的通配符必须转义，否则会造成客户想查询包含这些特殊字符的数据时，这些特殊字符却被解析为通配符。不与 LIKE 一同使用的通配符将解释为常量而非模式。 注意使用通配符的索引性能问题： a) like的第一个字符是\’%\’或\’_\’时，为未知字符不会使用索引, sql会遍历全表。 b) 若通配符放在已知字符后面，会使用索引。 网上有这样的说法，不过我在MSSQL中使用 ctrl+L 执行语法查看索引使用情况却都没有使用索引，可能在别的数据库中会使用到索引吧…… 截图如下：

有两种将通配符转义为普通字符的方法：

结束语：感谢你耐心的观看。恭喜你， SQL安全攻防你已经入门了…… 原文 http://www.cnblogs.com/heyuquan/archive/2012/10/31/2748577.html