（一）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語句拼接。