sql注入大家都不陌生，是一種常見的攻擊方式，攻擊者在界面的表單信息或url上輸入一些奇怪的sql片段，例如“or ‘1'='1'”這樣的語句，有可能入侵參數(shù)校驗(yàn)不足的應(yīng)用程序。所以在我們的應(yīng)用中需要做一些工作，來防備這樣的攻擊方式。在一些安全性很高的應(yīng)用中，比如銀行軟件，經(jīng)常使用將sql語句全部替換為存儲(chǔ)過程這樣的方式，來防止sql注入，這當(dāng)然是一種很安全的方式，但我們平時(shí)開發(fā)中，可能不需要這種死板的方式。

mybatis框架作為一款半自動(dòng)化的持久層框架，其sql語句都要我們自己來手動(dòng)編寫，這個(gè)時(shí)候當(dāng)然需要防止sql注入。其實(shí)Mybatis的sql是一個(gè)具有“輸入+輸出”功能，類似于函數(shù)的結(jié)構(gòu)，如下：

<select id=“getBlogById“ resultType=“Blog“ parameterType=”int”><br>
    select id,title,author,content from blog where id=#{id}
 
</select>

這里，parameterType標(biāo)示了輸入的參數(shù)類型，resultType標(biāo)示了輸出的參數(shù)類型。回應(yīng)上文，如果我們想防止sql注入，理所當(dāng)然地要在輸入?yún)?shù)上下功夫。上面代碼中高亮部分即輸入?yún)?shù)在sql中拼接的部分，傳入?yún)?shù)后，打印出執(zhí)行的sql語句，會(huì)看到sql是這樣的：

select id,title,author,content from blog where id = ?

不管輸入什么參數(shù)，打印出的sql都是這樣的。這是因?yàn)閙ybatis啟用了預(yù)編譯功能，在sql執(zhí)行前，會(huì)先將上面的sql發(fā)送給數(shù)據(jù)庫進(jìn)行編譯，執(zhí)行時(shí)，直接使用編譯好的sql，替換占位符“？”就可以了。因?yàn)閟ql注入只能對(duì)編譯過程起作用，所以這樣的方式就很好地避免了sql注入的問題。

mybatis是如何做到sql預(yù)編譯的呢？其實(shí)在框架底層，是jdbc中的PreparedStatement類在起作用，PreparedStatement是我們很熟悉的Statement的子類，它的對(duì)象包含了編譯好的sql語句。這種“準(zhǔn)備好”的方式不僅能提高安全性，而且在多次執(zhí)行一個(gè)sql時(shí)，能夠提高效率，原因是sql已編譯好，再次執(zhí)行時(shí)無需再編譯。

話說回來，是否我們使用mybatis就一定可以防止sql注入呢？當(dāng)然不是，請看下面的代碼：

<select id=“orderBlog“ resultType=“Blog“ parameterType=”map”>
 
    select id,title,author,content from blog order by ${orderParam}
 
</select>

仔細(xì)觀察，內(nèi)聯(lián)參數(shù)的格式由“#{xxx}”變?yōu)榱?{xxx}。如果我們給參數(shù)“orderParam”賦值為”id”,將sql打印出來，是這樣的：

select id,title,author,content from blog order by id

顯然，這樣是無法阻止sql注入的。在mybatis中，”${xxx}”這樣格式的參數(shù)會(huì)直接參與sql編譯，從而不能避免注入攻擊。但涉及到動(dòng)態(tài)表名和列名時(shí)，只能使用“${xxx}”這樣的參數(shù)格式，所以，這樣的參數(shù)需要我們在代碼中手工進(jìn)行處理來防止注入。

結(jié)論：在編寫mybatis的映射語句時(shí)，盡量采用“#{xxx}”這樣的格式。若不得不使用“${xxx}”這樣的參數(shù)，要手工地做好過濾工作，來防止sql注入攻擊。

以上就是小編為大家?guī)淼膉ava持久層框架mybatis防止sql注入的方法全部內(nèi)容了，希望大家多多支持腳本之家~

最新評(píng)論