您好,登錄后才能下訂單哦!
這篇文章給大家介紹mybatis使用${}時sql注入的問題怎么解決,內容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。
最近在上線項目的時候,代碼審查沒有通過,提示有sql注入的風險。
ORDER BY ${orderBy}
很簡單的一個排序字段,但是因為使用 ${} 占位符的原因,有sql注入的風險,相信大家平時也經常會使用這個占位符,不知道有沒有考慮sql注入的問題,下面簡單介紹下 #{} 和 ${} 的區別以及為什么使用 ${} 會有sql注入的問題。
#{}是一個參數占位符,對于String類型會自動加上"",其他類型不加。由于Mybatis采用預編譯,其后的參數不會再進行SQL編譯,所以一定程度上防止SQL注入。
${}是一個簡單的String替換,字符串是什么,解析就是什么。
類如order by。假如前端傳的參數是id(假設id是String類型),對于order by #{id},對應的sql語句就是 order by “id”;對于order by ${id},對應的sql語句則是order by id。這種情況,當用戶傳參為id && 1=1 的時候,就會產生難以預計的后果。
在原實體類里加入一個map
public Map<String,String> indexMap=new HashMap<String,String>(){ { put("spaceId","space_id"); // key為前端傳的值,value為數據庫對應的列值 put("optTime","opt_time"); } };
當傳參時,判斷參數是否在map的key中,如果存在的話,就把對應的value作為排序的依賴條件。
if(paramOptLog.getOrderBy()!=null &&Strings.isNullOrEmpty(paramOptLog.getOrderBy())){ OptLog optLog=new OptLog(); paramOptLog.setOrderBy(optLog.indexMap.getOrDefault(paramOptLog.getOrderBy(), "id")); } List<OptLog> list = optLogMapper.query4Page(paramOptLog); }
總結就是通過映射,由程序員來決定 ${} 傳的參數,即將動態sql轉成靜態sql的方式可以解決這個問題,這樣在實際調用的時候就不會有sql注入的風險了。
不會進行預編譯,會被sql注入
注入方式如下:
密碼隨便輸一個就可以通過驗證,只要用戶名正確即可。
這樣輸入后查詢語句在數據庫中如下:
select id,username,password from userLogin where username='admin' OR 1=1 and password='23'
sql解釋:AND優先級高于OR 首先判斷后面1=1 and password='23'為false,然后判斷前面username='admin'為true中間
連接為OR即最后為true OR false 最后還是為true,就直接通過驗證,能夠正常登陸admin用戶。
這樣會進行預編譯,能夠防止sql注入。sql注入只有在編譯時才有效,而預編譯的時候是用個?代替參數,真正執行時才把參數替換?。
關于mybatis使用${}時sql注入的問題怎么解決就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。