在java中数据库交交互涉及及到3种：
第⼀是jdbc,直接使⽤的是⾮预编译Statement对象，将参数通过 +直接在sql中执⾏。
第⼆是mybatis，通过$将来⾃前端的参数直接拼接在sql中。
第三是hibernate使⽤， 对于直接执⾏hql或sql语句通过+直接拼接到sql语句中。
常见的宽字节注⼊、延时盲注、布尔盲注、报错注⼊、Cookie注⼊等
绕过WAR:编码解码绕过，⼤写⼩绕过，混合双写绕过等
第⼀在mybatis中对于in,like,order by，not in等后边直接跟参数的，使⽤$占位会报错，因此必须⼿动使
⽤基于各⾃关键字的防注⼊⽅式解决注⼊问题。例1like，通过select * from student_table where
student_name like concat('%',#{name}, '%') 解决 select * from student_table where student_name
like '%#{tom}%' 。例2 in：通过select * from student_table where student_id in
<foreach collection="list" item="id" index="index" open="(" close=")" separator=",">
#{id}
</foreach>
</select>
解决select * from student_table where student_id in (#{id})【报错】
第⼆是如果前端的参数直接作为了sql语句where之前的字段名称，预编译将不能防御。
SQL注⼊修复方案：
1、如果参数源于前端且⽤户可控，对于直接拼接where的内容值【⾮关键字前】对于Mybatis使⽤#， hibernate，jdbc使⽤预编译对象匹配防⽌预编译。2、对于参数前应⽤了in,like的关键字使⽤各关键字提 供的解决⽅案防⽌预编译。
3、如果业务需要将前端的参数作为数据库数据表中的字段直接拼接，需要通 过⽩名单匹配，也就是说将前端的参数作为key，从后端维护好的⽩名单中找到真正的value，将value拼 接到sql中。
4、对于较⽼的项⽬，因为⼈⼒的成本产品⽆法使⽤预编译处理注⼊，只能通过设置⼀个全 局过滤器基于⿊名单防御，此⽅案不建议作为防御的合理措施，因为⿊名单难以维护，经常被绕过。
5、能限制参数的类型和⻓度就在前端直接限制。
