（一）Mybatis注入问题
Mybatis是目前比较常用的ORM的框架，一般与SpringMVC框架整合较多，但使用不当会有SQL注入的风险。
Mybatis里mapper中SQL语句的写法支持两种形式的占位符，一种是#{value}一种是${value}.
使用#进行占位时，如：
<selectid="selectUsername"resultType="com.example.bean.Admin">
select * from admin where username='#{username}'
</select>
内部实现是使用了JDBC预编译技术：
String sql = “select * from admin where username=?” ;
PreparedSatement ps = conn.prepareStatement(sql) ;
Ps.setString(“admin”, username) ;
但是使用$进行占位时，在内部实现中是字符串拼接：
<selectid="selectUsername"resultType="com.example.bean.Admin">
select * from admin where username='${value}'
</select>
代码测试一下：
如果使用$占位符，是存在SQL注入风险的，一旦没有经过校验就会有风险。
因此，在审计中，一般要看mapper.xml或者一些实现的Mapper接口中的注解里是否有使用$占位符的情况，如果使用了则说明很大几率会有问题。
（二）Hibernet注入问题
Hibernet框架同样都支持SQL语句拼接的情况，看以下代码：
这里的input参数使用的拼接的方式进入了查询中，明显是有问题的，可以带入单引号引发注入漏洞。
安全的方式是使用占位符的方式，然后使用setXXX来填补占位符，内部实现是基于预编译的，这样就不会存在注入了。
（三）SpringMVC框架XSS问题
SpringMVC并没有针对XSS进行统一的解决，因此寻找代码安全问题和传统的审计思路一致。
比如：
当SpringMVC和其他第三方模板进行整合时，比如和Freemarker进行整合，模板是不会对绑定数据进行自动净化处理的，因此也会存在XSS问题。
（四）Freemarker模板注入问题
目前比较流行的Freemarker和Velocity都有模板注入漏洞，可以直接执行系统命令或者getshell。
SpringMVC与Freemarker整合，当用户可以控制模板文件内容，包含但不限于编辑自定义模板、用户输入拼接在模板串中等：
CreateHtmlFromString的代码如下，即编译给定的模板字符串和数据，生成HTML进行输出：
当username为恶意模板语法时，会产生服务器端攻击，包括但不限于命令执行、getshell等：
新建一个FreemarkerView，可以参考
org.springframework.web.servlet.view.freemarker.FreeMarkerView的实现，然后在
initApplicationContext方法中加入下面两行代码：
（五）spring jpa
@Autowired
private EntityManager emf ;
利用的EntityManager做原始的SQL语句拼接。