您好,登錄后才能下訂單哦!
這篇文章主要講解了“Mybatis防止sql注入原理是什么”,文中的講解內容簡單清晰,易于學習與理解,下面請大家跟著小編的思路慢慢深入,一起來研究和學習“Mybatis防止sql注入原理是什么”吧!
SQL 注入是一種代碼注入技術,用于攻擊數據驅動的應用,惡意的SQL 語句被插入到執行的實體字段中(例如,為了轉儲數據庫內容給攻擊者)。[摘自] SQL注入 - 維基百科SQL注入,大家都不陌生,是一種常見的攻擊方式。攻擊者在界面的表單信息或URL上輸入一些奇怪的SQL片段(例如“或'1'='1'”這樣的語句),有可能入侵參數檢驗不足的應用程序。所以,在我們的應用中需要做一些,來防備這樣的攻擊方式。在一些安全性要求很高的應用(比如銀行軟件),經常使用將 SQL 語句全部替換為存儲過程這樣的方式,來防止SQL注入。當然這的英文一種很安全的方式,但我們平時開發中,可能不需要這種死板的方式。
MyBatis的框架作為一款半自動化的ORM框架,其SQL語句都要我們自己手動編寫,這個時候當然需要防止SQL 注入。其實,MyBatis的SQL的是一個具有“ 輸入+ 輸出 ”的功能,類似于函數的結構,如下:
<select id =“ getBlogById ”resultType =“ Blog ”parameterType =“ int ”> SELECT id,title,author,content FROM blog WHERE id =#{id} </select>
這里,參數類型表示了輸入的參數類型,與resultType表示了輸出的參數類型,回應上文,如果我們想防止SQL注入,理所當然地要在輸入參數上下功夫。上面代碼中黃色高亮即輸入參數在SQL中拼接的部分,傳入參數后,打印出執行的SQL語句,會看到SQL是這樣的:
SELECT id,title,author,content FROM blog WHERE id =?
不管輸入什么參數,打印出的SQL都是這樣的這是因為MyBatis的啟用了預編譯功能,在SQL執行前,會先將上面的SQL發送給數據庫進行編譯;執行時,直接使用編譯好的SQL ,替換占位符“?”就可以了。因為SQL注入只能對編譯過程起作用,所以這樣的方式就很好地避免了SQL注入的問題。
其原因就是:采用了JDBC的PreparedStatement,就會將sql語句:“select id,no from user where id =?” 預先編譯好,也就是SQL引擎會預先進行語法分析,產生語法樹,生成執行計劃,也就是說,后面你輸入的參數,無論你輸入的是什么,都不會影響該SQL語句的語法結構了,因為語法分析已經完成了,而語法分析主要是分析sql命令,比如select,from,where,and,or,order by等等。
所以即使你后面輸入了這些sql命令,也不會被當成sql命令來執行了,因為這些SQL命令的執行,必須先得通過語法分析,生成執行計劃,既然語法分析已經完成,已經預編譯過了,那么后面輸入的參數,是絕對不可能作為SQL命令來執行的,只會被當做字符串字面值參數。
所以的sql語句預編譯可以防御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注入。
如果我們通過語句后用了訂單$ {},那么不做任何處理的時候是存在SQL注入危險的。你說怎么防止,那我只能悲慘的告訴你,你得手動處理過濾一下輸入的內容。如判斷一下輸入的參數的長度是否正常(注入語句一般很長),更精確的過濾則可以查詢一下輸入側的參數是否在預期的參數集合中。
sql注入大家都不陌生,是一種常見的攻擊方式,攻擊者在界面的表單信息或url上輸入一些奇怪的sql片段,例如“or ‘1'='1'”這樣的語句,有可能入侵參數校驗不足的應用程序。
所以在我們的應用中需要做一些工作,來防備這樣的攻擊方式。在一些安全性很高的應用中,比如銀行軟件,經常使用將sql語句全部替換為存儲過程這樣的方式,來防止sql注入,這當然是一種很安全的方式,但我們平時開發中,可能不需要這種死板的方式。
mybatis框架作為一款半自動化的持久層框架,其sql語句都要我們自己來手動編寫,這個時候當然需要防止sql注入。其實Mybatis的sql是一個具有“輸入+輸出”功能,類似于函數的結構,如下:
<select id=“getBlogById“ resultType=“Blog“ parameterType=”int”><br> select id,title,author,content from blog where id=#{id} </select>
這里,parameterType標示了輸入的參數類型,resultType標示了輸出的參數類型。回應上文,如果我們想防止sql注入,理所當然地要在輸入參數上下功夫。上面代碼中高亮部分即輸入參數在sql中拼接的部分,傳入參數后,打印出執行的sql語句,會看到sql是這樣的:
select id,title,author,content from blog where id = ?
不管輸入什么參數,打印出的sql都是這樣的。這是因為mybatis啟用了預編譯功能,在sql執行前,會先將上面的sql發送給數據庫進行編譯,執行時,直接使用編譯好的sql,替換占位符“?”就可以了。因為sql注入只能對編譯過程起作用,所以這樣的方式就很好地避免了sql注入的問題。
mybatis是如何做到sql預編譯的呢?其實在框架底層,是jdbc中的PreparedStatement類在起作用,PreparedStatement是我們很熟悉的Statement的子類,它的對象包含了編譯好的sql語句。這種“準備好”的方式不僅能提高安全性,而且在多次執行一個sql時,能夠提高效率,原因是sql已編譯好,再次執行時無需再編譯。
話說回來,是否我們使用mybatis就一定可以防止sql注入呢?當然不是,請看下面的代碼:
<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防止sql注入原理是什么”的內容了,經過本文的學習后,相信大家對Mybatis防止sql注入原理是什么這一問題有了更深刻的體會,具體使用情況還需要大家實踐驗證。這里是億速云,小編將為大家推送更多相關知識點的文章,歡迎關注!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。