背景：
某一天准备上线，合完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中固定排序字段
- 模糊查询 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