SQL注入起因
SQL注入是一种常见的攻击方式，攻击者或者误操作者通过表单信息或者URL输入一些异常的参数，传入服务端进行SQL处理，可能会出现这样的情况delete from app_poi where poi_id = (输入参数)：
输入参数：10 or 1 = 1
SQL拼接：delete from app_poi where poi_id = (10 or 1 = 1)
执行结果：app_poi中的所有数据都会被delete
这种问题出现的原因可能是攻击者故意为之，也可能是误操作，那么服务端该如何处理，避免这样的问题出现呢？
MyBatis
MyBatis是一种半自动化持久化框架，所有SQL操作都需要我们通过配置文件或者注解的方式手动编辑，它提供了一种类函数的功能，用户提供输入，MyBatis根据输入类型和输入参数进行验证，如果参数没有问题，那么MyBatis就针对合法的输入提供输出，即
用户输入参数+用户输入类型 —> MyBatis检测 —> 返回输出
接下来通过配置文件和注解两种方式来进行说明
- 配置文件：
<delete id= "deletePoiById" parameterType= "java.lang.Integer" > DELETE FROM app_poi where poi_id = #{poiId} </delete> |
- 基于注解
@delete ( "delete from app_poi where poi_id = #{poiId}" ) public void deletePoiById( @Param ( "poiId" ) Integer poiId); |
MyBatis对用户输入的数据会检测其类型是否和parameterType标识的类型一致，如果一致，则进行后续拼接处理，否则抛出异常，SQL就不会执行
对于10 or 1 = 1这种输入，和java.lang.Integer类型不同，就会abort并抛出异常
原理
MyBatis使用#{}防止SQL注入，其实使用的是PreparedStatement，PreparedStatement会对执行SQL进行预编译，这个过程是发生在数据库服务端，也就是说，对于PreparedStatement的SQL需要两次网络请求，首次是获取PreparedStatement，第二次才是发起SQL执行；
PreparedStatement会对SQL中输入的参数进行检测，并在SQL都是用问号来设置占位符，即只允许传入一个参数，像（10 or 1 = 1）这种明显不会被占位符所接受
String类型SQL注入
对于数字类型参数#{}可以很好的解决SQL注入，其原因不难理解，那么对于string类型的呢？Mybatis只是使用了一个占位符并不能解决该问题
<delete id= "deletePoiById" parameterType= "java.lang.String" > DELETE FROM app_poi where content = #{content} </delete> |
如果content的内容是“美食 or 1 = 1”，那么数据将会被全部清除
解决该问题，还是结合传统方式，使用正则表达式匹配，总结常见的需要摒弃的string，替换为空即可，例如string包含
and|exec|insert|select|delete|update|count|*|%|chr|mid|master|truncate|char|declare|; |or|-|+|,等
