SQL反模式学习笔记21 SQL注入

2014-10-17 14:13:57 

目标：编写SQL动态查询，防止SQL注入

　　通常所说的“SQL动态查询”是指将程序中的变量和基本SQL语句拼接成一个完整的查询语句。

 

反模式：将未经验证的输入作为代码执行

　　当向SQL查询的字符串中插入别的内容，而这些被插入的内容以你不希望的方式修改了查询语法时，SQL注入就成功了。

　　传统的SQL注入案例中，所插入的内容首先完成了一个查询，然后再执行第二个完整的查询逻辑比如：@bugId的值是

      1234;Delete from Bugs，最后的SQL语句变成如下格式：

      Select * from Bugs where bugId = 1234;Delete from Bugs

　　1、意外无处不在

         由于字符串引起的语法错误，SQL语句是不会被执行的。

　　    风险较大的是产生的SQL没有任何语法错误，并且以一种你所不希望的方式执行。

　　2、对Web安全的严重威胁

　　　　当攻击者能够使用SQL注入操控你的SQL查询语句时，就变成了一个巨大的威胁。

           通常做法是在参数后插入额外的字符串，改变对应SQL语句的意义，例如：

          Update Account 

          set password = SHA2('zyxzy'

          where accountId = 123 or true  --在传入accountId参数等于123的后面，添加了 or true

          理解SQL注入的关键，也是如何防止SQL注入的关键：SQL注入是通过在SQL语句被数据库解析之前，

          以修改其语法的形式工作的。只要在解析语句之前插入动态部分，就存在SQL注入的风险。

　　3、寻找解决方法

　　　　（1）转义：对传入的参数字符串进行转义操作，使它们不至于成为字符串的结束符。

                         使用2个连续的单引号或者反斜杠来转义。实现原理是在将应用程序中的数据插入到SQL语句之前

                         就进行转换。这种技术能减少由于动态内容中不匹配是引号做造成的SQL注入的风险，但在非字符串

                         内容的情况下，这种技术就会失效。

　　　　（2）查询参数：查询参数的做法是在准备查询语句的时候，在对应参数的地方使用“参数占位符”。随后，

                         在执行这个预先准备好的查询时提供一个参数。

                         该方法的确是应对SQL注入的强劲解决方案，但是这还不是一个通用的解决方案，因为查询参数总是被视为是一个字面值。

　　　　　　（a）多个值的列表不可以当成单一参数；

　　　　　　（b）表名无法作为参数；

                （c）列名无法作为参数；

                （d）SQL关键字无法作为参数；

　　　　（3）存储过程：存储过程是包含固定的SQL语句，这些语句在定义这个存储过程的时候被解析的。

                 在存储过程也可以使用SQL动态查询的，这样也存在安全隐患。

　　　　（4）数据访问框架ORM：对于所有允许你使用字符串方式传入SQL语句的框架来说，都无法抵御SQL注入的攻击。

 

如何识别反模式：几乎所有的数据库应用程序都动态地构建SQL语句，如果使用拼接字符串的形式或者将变量插入到字符串的

　　方法来构建SQL语句，这样的sql语句就会受到SQL注入攻击的威胁。

 

合理使用反模式：没有任何理由使用反模式

 

解决方案：

　　1、过滤输入内容，将所有不合法的字符从用户输入中剔除掉。

　　2、参数化动态内容：如果查询中的变化部分是一些简单的类型，应该使用查询参数将其和SQL表达式分离。

         如果是在RDBMS解析完SQL语句之后才插入这个参数值，没有哪种SQL注入的功能能改变一个参数化了查询的语法结构。

         即使攻击者尝试使用带有恶意的参数值，诸如123 or true ，关系型数据库管理系统也会将这个字符串当成一个完整的值插入     

           Update Account 

           set password = SHA2('zyxzy'

           where accountId ='123 or true' --当做一个完整的字符串而不会造成威胁

　　3、给动态输入的值加引号

          参数查询通常来说是最好的解决方案，但是在有些特殊的情况下，参数的占位符会导致查询优化器无法选择使用

          哪个索引来进行优化查询。

　　4、找个可靠的人来帮你审查SQL语句

          在检查代码是否包含SQL注入风险的时候，参考一下几点：

　　　　（1）找出所有使用了程序变量、字符串链接或者替换等方法组成的SQL语句。

　　　　（2）跟踪在SQL语句中使用的动态内容的来源。找出所有的外部输入，比如用户输入、文件、系统环境、网络服务、

                  第三方代码，甚至于从数据库中获取的字符串。

           （3）假设任何外部内容都是潜在的威胁，对于不受信任的内容都要进行过滤、验证或者使用数组映射的方式来处理。

　　　　（4）在将外部数据合并到SQL语句时，使用查询参数，或者用稳健的转义函数预先处理。

　　　　（5）在存储过程的代码以及任何其他使用SQL动态查询语句的地方都做同样的检查。

 

结论：让用户输入内容，但永远别让用户输入代码