mybatis 防止sql注入

SQL注入是一種代碼注入技術,用於攻擊數據驅動的應用,惡意的SQL語句被插入到執行的實體字段中(例如,爲了轉儲數據庫內容給攻擊者)。[摘自] SQL injection - Wikipediagit

SQL注入,你們都不陌生,是一種常見的攻擊方式。攻擊者在界面的表單信息或URL上輸入一些奇怪的SQL片斷(例如「or ‘1’=’1’」這樣的語句),有可能入侵參數檢驗不足的應用程序。因此,在咱們的應用中須要作一些工做,來防備這樣的攻擊方式。在一些安全性要求很高的應用中(好比銀行軟件),常常使用將SQL語句所有替換爲存儲過程這樣的方式,來防止SQL注入。這固然是一種很安全的方式,但咱們平時開發中,可能不須要這種死板的方式。github

MyBatis框架做爲一款半自動化的持久層框架,其SQL語句都要咱們本身手動編寫,這個時候固然須要防止SQL注入。其實,MyBatis的SQL是一個具備「輸入+輸出」的功能,相似於函數的結構,以下:數據庫

 

<select id="getBlogById" resultType="Blog" parameterType=」int」>安全

         SELECT id,title,author,contentmybatis

         FROM blog框架

WHERE id=#{id}函數

</select>對象

 

這裏,parameterType表示了輸入的參數類型,resultType表示了輸出的參數類型。迴應上文,若是咱們想防止SQL注入,理所固然地要在輸入參數上下功夫。上面代碼中黃色高亮即輸入參數在SQL中拼接的部分,傳入參數後,打印出執行的SQL語句,會看到SQL是這樣的:blog

SELECT id,title,author,content FROM blog WHERE id = ?ip

無論輸入什麼參數,打印出的SQL都是這樣的。這是由於MyBatis啓用了預編譯功能,在SQL執行前,會先將上面的SQL發送給數據庫進行編譯;執行時,直接使用編譯好的SQL,替換佔位符「?」就能夠了。由於SQL注入只能對編譯過程起做用,因此這樣的方式就很好地避免了SQL注入的問題。

【底層實現原理】MyBatis是如何作到SQL預編譯的呢?其實在框架底層,是JDBC中的PreparedStatement類在起做用,PreparedStatement是咱們很熟悉的Statement的子類,它的對象包含了編譯好的SQL語句。這種「準備好」的方式不只能提升安全性,並且在屢次執行同一個SQL時,可以提升效率。緣由是SQL已編譯好,再次執行時無需再編譯。

話說回來,是否咱們使用MyBatis就必定能夠防止SQL注入呢?固然不是,請看下面的代碼:

<select id="getBlogById" resultType="Blog" parameterType=」int」>

         SELECT id,title,author,content

         FROM blog

WHERE id=${id}

</select>

仔細觀察,內聯參數的格式由「#{xxx}」變爲了「${xxx}」。若是咱們給參數「id」賦值爲「3」,將SQL打印出來是這樣的:

SELECT id,title,author,content FROM blog WHERE id = 3

(上面的對比示例是我本身添加的,爲了與前面的示例造成鮮明的對比。)

<select id="orderBlog" resultType="Blog" parameterType=」map」>

         SELECT id,title,author,content

         FROM blog

ORDER BY ${orderParam}

</select>

仔細觀察,內聯參數的格式由「#{xxx}」變爲了「${xxx}」。若是咱們給參數「orderParam」賦值爲「id」,將SQL打印出來是這樣的:

SELECT id,title,author,content FROM blog ORDER BY id

顯然,這樣是沒法阻止SQL注入的。在MyBatis中,「${xxx}」這樣格式的參數會直接參與SQL編譯,從而不能避免注入攻擊。但涉及到動態表名和列名時,只能使用「${xxx}」這樣的參數格式。因此,這樣的參數須要咱們在代碼中手工進行處理來防止注入。

【結論】在編寫MyBatis的映射語句時,儘可能採用「#{xxx}」這樣的格式。若不得不使用「${xxx}」這樣的參數,要手工地作好過濾工做,來防止SQL注入攻擊。

 

#{}:至關於JDBC中的PreparedStatement

${}:是輸出變量的值

簡單說,#{}是通過預編譯的,是安全的${}是未通過預編譯的,僅僅是取變量的值,是非安全的,存在SQL注入。

若是咱們order by語句後用了${},那麼不作任何處理的時候是存在SQL注入危險的。你說怎麼防止,那我只能悲慘的告訴你,你得手動處理過濾一下輸入的內容。如判斷一下輸入的參數的長度是否正常(注入語句通常很長),更精確的過濾則能夠查詢一下輸入的參數是否在預期的參數集合中。

相關文章
相關標籤/搜索