怎么確定SQL注入死透了

小編給大家分享一下怎么確定SQL注入死透了，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

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

后來(lái)的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ù)還多！

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

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

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

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

但不代表著沒有，只是門檻提高了。我們以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ā)生問(wèn)題的，還是LIKE和IN等類似的語(yǔ)句。

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

SELECT * FROM order WHERE name like '%#{name}%'  //會(huì)報(bào)語(yǔ)法錯(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}, ‘%’) //正確的寫法

同樣的問(wèn)題，存在于IN語(yǔ)句。

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

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

以上是“怎么確定SQL注入死透了”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！