从orderby引发的SQL注入问题的思考

背景：

　　某一天准备上线，合完master之后准备发布了，忽然公司的代码安全监测提示了可能在代码中存在sql注入的风险，遂即检查，发现sql注入问题

既然碰到了这个问题，那就了简单了解下sql注入

基础知识：#

SQL注入基本原理：#

　　所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

　　注入攻击的本质，是把用户输入的数据当做代码执行。这里有两个关键条件，第一个是用户能够控制输入；第二个是原本程序要执行的代码，拼接了用户输入的数据。

SQL注入类型#

按照注入点类型来分类

(1).数字型注入点(当输入的参数为整形时，如果存在注入漏洞，可以认为是数字型注入。)

sql原型：  select * from aaa where id = 1  ，有如下种可能：

　　1). 加单引号,对应的sql： select * from aaa where id=3’   这时sql语句出错，程序无法正常从数据库中查询出数据，就会抛出异常；

　　2).加or 1=1,对应的sql:   select*from aaa where id=3 or 1=1  这个时候能够查询到所有的结果

　　3).加上 and 1=1 对应的sql：select * from aaa where id=3 and 1=1     不能查询到结果

(2).字符型注入点(当输入的参数为字符串时，称为字符型。字符型和数字型最大的一个区别在于，数字型不需要单引号来闭合，而字符串一般需要通过单引号来闭合的。)

sql原型： select * from aaa where name='admin'  ，有如下种可能：

　　1).加单引号:

select * from aaa where name ='admin' and 1=1 -- '

 这种注入方式并不会影响查询结果

　　2).加union：

select name from aaa where name='1' union select database()#'

这种的结果就是把数据库信息泄露出去。

　　3).加or

select name from aaa where name='11' or '1234 '='1234'

这种就是导致查询的结果并不是期望的结果，导致数据泄露

(3).搜索型注入点(说明一下，搜索型注入也无他，前加%' 后加 and '%'='  对于MYSQL数据库，后面可以吧 and '%'='换成--)

这是一类特殊的注入类型。这类注入主要是指在进行数据搜索时没过滤搜索参数，一般在链接地址中有“keyword=关键字”，有的不显示在的链接地址里面，而是直接通过搜索框表单提交。此类注入点提交的 SQL 语句，其原形大致为：select * from 表名 where 字段 like '%关键字%'。

按照数据提交的方式来分类

（1）GET 注入

提交数据的方式是 GET , 注入点的位置在 GET 参数部分。比如有这样的一个链接http://xxx.com/news.php?id=1 , id 是注入点。

（2）POST 注入

使用 POST 方式提交数据，注入点位置在 POST 数据部分，常发生在表单中。

（3）Cookie 注入

HTTP 请求的时候会带上客户端的 Cookie, 注入点存在 Cookie 当中的某个字段中。

（4）HTTP 头部注入

注入点在 HTTP 请求头部的某个字段中。比如存在 User-Agent 字段中。严格讲的话，Cookie 其实应该也是算头部注入的一种形式。因为在 HTTP 请求的时候，Cookie 是头部的一个字段。

按照执行效果来分类#

（1）基于布尔的盲注，即可以根据返回页面判断条件真假的注入。

（2）基于时间的盲注，即不能根据页面返回内容判断任何信息，用条件语句查看时间延迟语句是否执行（即页面返回时间是否增加）来判断。

（3）基于报错注入，即页面会返回错误信息，或者把注入的语句的结果直接返回在页面中。

（4）联合查询注入，可以使用union的情况下的注入。

（5）堆查询注入，可以同时执行多条语句的执行时的注入。

基本原理了解了一些之后，再来一个案例吧

案例：#

持久层框架：MyBatis

　　　　  <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
            <version>3.2.1</version>
        </dependency>

sql内容：

<if test="query.orderBy != null">
            ORDER BY ${query.orderBy}
        </if>

背景：orderBy使用不规范也会引发sql注入吗？

例如：

select * from aaa order by id and(updatexml(1,concat(0x7e,(select system_user())),0));

这里介绍下：UPDATEXML (XML_document, XPath_string, new_value); 

第一个参数：XML_document是String格式，为XML文档对象的名称，文中为Doc 
第二个参数：XPath_string (Xpath格式的字符串)   (XPATH格式：http://www.cnblogs.com/Loofah/archive/2012/05/10/2494036.html)

第三个参数：new_value，String格式，替换查找到的符合条件的数据 
作用：改变文档中符合条件的节点的值

执行上面的sql，通过报错内容获取当前连接数据库的用户名

[SQL]select * from aaa order by id and(updatexml(1,concat(0x7e,(select system_user())),0));
[Err] 1105 - XPATH syntax error: '~root@localhost'

在mybatis中如何避免？

在mybatis中，#{} 相当于 jdbc中的preparedstatement，就是说传递过来的参数会自动加上单引号，而${} 是直接输出变量的值。一般来说,使用#{}语法,MyBatis会产生PreparedStatement语句中，并且安全的设置PreparedStatement参数，这个过程中MyBatis会进行必要的安全检查和转义。比如这样：

执行SQL：Select * from aaa where name = #{name}
参数：aaa
解析后执行的SQL：Select * from aaa where name = ？

也就是说#{}更安全一些。但是order by 明显是不能使用这种方式的。order by 之后如果使用  #{} 使用时则变成了 order by '...' 那么sql就直接报错了

避免该种类型的sql注入的有效措施就是在程序中判断排序字段 以保证xml中只可能出现某些情况或者在xml中固定排序字段

Mybatis中其他易产生SQL注入的场景

•  模糊查询 like 

　　　　正常程序： select * from aaa where name like '%${likeColumn}%'  可能会存在sql注入问题

　　　　修改后：

select * from aaa where name like concat('%',#{likeColumn},'%')

　　　　修改点：从 ${} 改为 #{}，从sql拼接到 concat方式

• in之后的参数

　　　　正常程序： Select * from aaa where id in (${id}) 

　　　　修改后：

select * from aaa where id in
<foreach collection="ids" item="item" open="("separator="," close=")">#{item} </foreach>　

ok,先简单对sql注入有个了解。

https://blog.csdn.net/m0_37438418/article/details/80260813  一道综合渗透题引发的updatexml()注入思考

https://www.cnblogs.com/moxiaotao/p/9330711.html  Java框架之MybatisSQL注入漏洞

https://www.cnblogs.com/xuthus/p/9450805.html  SQL注入 (1) SQL注入类型介绍

https://blog.csdn.net/qq_30464257/article/details/84495884 如何判断是字符型注入还是整形注入

http://www.hackdig.com/?08/hack-5209.htm

https://msd.misuland.com/pd/3070888491219950886

https://www.open-open.com/lib/view/open1474963603800.html