Mybatis防止sql注入原理

SQL 注入是一種代碼注入技術(shù)，用于攻擊數(shù)據(jù)驅(qū)動(dòng)的應(yīng)用，惡意的SQL 語(yǔ)句被插入到執(zhí)行的實(shí)體字段中（例如，為了轉(zhuǎn)儲(chǔ)數(shù)據(jù)庫(kù)內(nèi)容給攻擊者）。[摘自] SQL注入 - 維基百科SQL注入，大家都不陌生，是一種常見(jiàn)的攻擊方式。攻擊者在界面的表單信息或URL上輸入一些奇怪的SQL片段（例如“或'1'='1'”這樣的語(yǔ)句），有可能入侵參數(shù)檢驗(yàn)不足的應(yīng)用程序。所以，在我們的應(yīng)用中需要做一些，來(lái)防備這樣的攻擊方式。在一些安全性要求很高的應(yīng)用（比如銀行軟件），經(jīng)常使用將 SQL 語(yǔ)句全部替換為存儲(chǔ)過(guò)程這樣的方式，來(lái)防止SQL注入。當(dāng)然這的英文一種很安全的方式，但我們平時(shí)開(kāi)發(fā)中，可能不需要這種死板的方式。

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

<select id =“ getBlogById ”resultType =“ Blog ”parameterType =“ int ”>
         SELECT id，title，author，content
FROM blog
WHERE id =＃{id}
</select>

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

SELECT id，title，author，content FROM blog WHERE id =？

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

底層實(shí)現(xiàn)原理

其原因就是：采用了JDBC的PreparedStatement，就會(huì)將sql語(yǔ)句：“select id，no from user where id =？” 預(yù)先編譯好，也就是SQL引擎會(huì)預(yù)先進(jìn)行語(yǔ)法分析，產(chǎn)生語(yǔ)法樹(shù)，生成執(zhí)行計(jì)劃，也就是說(shuō)，后面你輸入的參數(shù)，無(wú)論你輸入的是什么，都不會(huì)影響該SQL語(yǔ)句的語(yǔ)法結(jié)構(gòu)了，因?yàn)檎Z(yǔ)法分析已經(jīng)完成了，而語(yǔ)法分析主要是分析sql命令，比如select，from，where，and，or，order by等等。

所以即使你后面輸入了這些sql命令，也不會(huì)被當(dāng)成sql命令來(lái)執(zhí)行了，因?yàn)檫@些SQL命令的執(zhí)行，必須先得通過(guò)語(yǔ)法分析，生成執(zhí)行計(jì)劃，既然語(yǔ)法分析已經(jīng)完成，已經(jīng)預(yù)編譯過(guò)了，那么后面輸入的參數(shù)，是絕對(duì)不可能作為SQL命令來(lái)執(zhí)行的，只會(huì)被當(dāng)做字符串字面值參數(shù)。

所以的sql語(yǔ)句預(yù)編譯可以防御SQL注入。而且在多次執(zhí)行同一個(gè)SQL時(shí)，能夠提高效率。原因是SQL已編譯好，再次執(zhí)行時(shí)無(wú)需再編譯。

話說(shuō)回來(lái)，是否我們使用的MyBatis就一定可以防止SQL注入呢當(dāng)然不是，請(qǐng)看下面的代碼？

<select id =“ getBlogById ”resultType =“ Blog ”parameterType =“ int ”>
         SELECT id，title，author，content
         FROM blog
WHERE id = $ {id}
</select>

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

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

（上面的對(duì)比示例是我自己添加的，為了與前面的示例形成鮮明的對(duì)比。）

<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打印出來(lái)是這樣的：

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

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

【結(jié)論】在編寫(xiě)MyBatis的映射語(yǔ)句時(shí)，盡量采用“ ＃ {xxx}”這樣的格式。若不得不使用“ $ {xxx}”這樣的參數(shù)，要手工地做好過(guò)濾工作，來(lái)防止SQL注入攻擊。

• ＃{}：相當(dāng)于JDBC中的PreparedStatement的
• $ {}：是輸出變量的值

簡(jiǎn)單說(shuō)，＃ {}是經(jīng)過(guò)預(yù)編譯的，是安全的 ; $ {}是未經(jīng)過(guò)預(yù)編譯的，僅僅是取變量的值，是非安全的，存在SQL注入。

如果我們通過(guò)語(yǔ)句后用了訂單$ {}，那么不做任何處理的時(shí)候是存在SQL注入危險(xiǎn)的。你說(shuō)怎么防止，那我只能悲慘的告訴你，你得手動(dòng)處理過(guò)濾一下輸入的內(nèi)容。如判斷一下輸入的參數(shù)的長(zhǎng)度是否正常（注入語(yǔ)句一般很長(zhǎng)），更精確的過(guò)濾則可以查詢一下輸入側(cè)的參數(shù)是否在預(yù)期的參數(shù)集合中。

Mybatis解決sql注入問(wèn)題

sql注入大家都不陌生，是一種常見(jiàn)的攻擊方式，攻擊者在界面的表單信息或url上輸入一些奇怪的sql片段，例如“or ‘1'='1'”這樣的語(yǔ)句，有可能入侵參數(shù)校驗(yàn)不足的應(yīng)用程序。

所以在我們的應(yīng)用中需要做一些工作，來(lái)防備這樣的攻擊方式。在一些安全性很高的應(yīng)用中，比如銀行軟件，經(jīng)常使用將sql語(yǔ)句全部替換為存儲(chǔ)過(guò)程這樣的方式，來(lái)防止sql注入，這當(dāng)然是一種很安全的方式，但我們平時(shí)開(kāi)發(fā)中，可能不需要這種死板的方式。

mybatis框架作為一款半自動(dòng)化的持久層框架，其sql語(yǔ)句都要我們自己來(lái)手動(dòng)編寫(xiě)，這個(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語(yǔ)句，會(huì)看到sql是這樣的：

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

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

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

話說(shuō)回來(lái)，是否我們使用mybatis就一定可以防止sql注入呢？當(dāng)然不是，請(qǐ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打印出來(lái)，是這樣的：

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

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

小結(jié)一下

在編寫(xiě)mybatis的映射語(yǔ)句時(shí)，盡量采用“#{xxx}”這樣的格式。若不得不使用“${xxx}”這樣的參數(shù)，要手工地做好過(guò)濾工作，來(lái)防止sql注入攻擊。

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論