本文轉(zhuǎn)載自微信公眾號(hào)「小姐姐味道」，作者小姐姐養(yǎng)的狗 。轉(zhuǎn)載本文請(qǐng)聯(lián)系小姐姐味道公眾號(hào)。  

[[386261]]

很長(zhǎng)一段時(shí)間，我認(rèn)為后端開發(fā)，在安全性方面最容易出問題的地方就在于SQL注入。通過 where 1=1這種魔幻的SQL寫法，就可以很容易的對(duì)一個(gè)存在問題的系統(tǒng)進(jìn)行攻擊，以至于最終演進(jìn)出sqlmap這樣的神器存在。

后來的fastjson刷新了我的認(rèn)知，這個(gè)框架也算是對(duì)互聯(lián)網(wǎng)安全概念的一種推動(dòng)。連不懂技術(shù)的老板，都知道fastjson快的要命，作為程序員安全理念就得到了一次提升。

為什么對(duì)sql注入情有獨(dú)鐘?因?yàn)殚_發(fā)人員和SQL打交道的地方太多了。甚至有的專門開發(fā)報(bào)表的同學(xué)，寫的SQL行數(shù)，比寫的代碼行數(shù)還多!

問題是。很久很久之前，早在10年前，就有人在喊SQL注入已經(jīng)死掉了，但時(shí)至今日，依然有一大批的SQL注入教程和SQL注入的案例。

SQL注入是漏洞之王，這可不是吹的。

當(dāng)然在這方面，PHP的貢獻(xiàn)最大，Java甘拜下風(fēng)。

SQL注入流行的原因，就是開發(fā)人員對(duì)自己太自信了，或者使用的工具太原始了，沒有經(jīng)過框架層進(jìn)行一次過濾。如果你用了Java界的MyBatis或者JPA，發(fā)生SQL注入的可能性就變的非常的低?，F(xiàn)在PHP也有了類似于thinkphp一樣的框架，代表著能搞的SQL注入漏洞已經(jīng)越來越少了。

但不代表著沒有，只是門檻提高了。我們以MyBatis為例，看一下到底還能不能發(fā)生SQL注入。

MyBatis依然存在SQL注入

使用Mybatis的同學(xué)，第一個(gè)接觸的概念，就是#和$的區(qū)別。這兩個(gè)符號(hào)非常的像Shell中的魔幻符號(hào)，但好在只有兩種情況。

• # 代表的是使用sql預(yù)編譯方式，安全可靠
• $ 代表著使用的是拼接方式，有SQL注入的風(fēng)險(xiǎn)

比如下面這個(gè)xml配置，就是一個(gè)絕對(duì)安全的寫法。因?yàn)檎麄€(gè)#{id}會(huì)被替換成?。

<select id="queryAll"  resultMap="resultMap"> 
  SELECT * FROM order WHERE id = #{id} 
</select> 

但可惜的是，有些場(chǎng)景，并不能使用預(yù)編譯方式(或者你僅僅是不知道或者懶)。像一些代碼重構(gòu)，把表名/列名/排序等字段，動(dòng)態(tài)傳入的時(shí)候，不可避免的就需要SQL拼接的方式，SQL注入依然有搞頭。

但更容易發(fā)生問題的，還是LIKE和IN等類似的語句。

下面是兩句Like模糊查詢的寫法，實(shí)際測(cè)試會(huì)發(fā)現(xiàn)，使用#竟然不好使了，會(huì)報(bào)錯(cuò)，需要使用sql拼接的$。問題由此發(fā)生。

SELECT * FROM order WHERE name like '%#{name}%'  //會(huì)報(bào)語法錯(cuò) 
SELECT * FROM order WHERE name like '%${name}%'  //可以運(yùn)行 

而正確的寫法，應(yīng)該使用函數(shù)拼接。但是工期壓死人，在不知不覺間，大多數(shù)人就選擇了簡(jiǎn)單的寫法。畢竟功能第一嘛，也是體現(xiàn)工作量的最主要方式。

SELECT * FROM order WHERE  name like concat(‘%’,#{name}, ‘%’) //正確的寫法 

同樣的問題，存在于IN語句。

in (#{tag}) //報(bào)錯(cuò) 
in (${tag}) //可以運(yùn)行 

既然幾個(gè)字符就可以運(yùn)行，當(dāng)然沒人選擇下面復(fù)雜的寫法。

tag in 
<foreach collection="tag" item="item" open="("separatosr="," close=")"> 
#{tag}  
</foreach> 

還有order by，也千萬不要掉以輕心，一不小心就會(huì)萬劫不復(fù)。

SELECT * FROM order order by createDate #{sortType} //報(bào)錯(cuò) 
SELECT * FROM order order by createDate ${sortType} //正常 

這種情況下，就需要把sortType搞成白名單了。不就一個(gè)ASC和DESC了，你給我傳一個(gè)長(zhǎng)長(zhǎng)的串，是怎么回事?

總結(jié)

SQL注入在2021年，依然存在，只不過門檻提高了?，F(xiàn)在SQL注入減少，都是框架的功勞，和程序員的水平?jīng)]半毛關(guān)系。sql拼接的情況永遠(yuǎn)不會(huì)消失，因?yàn)檫@是最快捷簡(jiǎn)單的方式，會(huì)讓人欲罷不能。無數(shù)的外包項(xiàng)目，十幾年躺尸不動(dòng)的系統(tǒng)比比皆是，寄希望于在框架層全部消滅SQL注入，是一個(gè)夢(mèng)想。

因?yàn)樗膶?duì)手，是人性的懶惰。誰也無法戰(zhàn)勝它。