怎么確定SQL注入死透了

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

很長一段時間，我認為后端開發，在安全性方面最容易出問題的地方就在于SQL注入。通過 where 1=1這種魔幻的SQL寫法，就可以很容易的對一個存在問題的系統進行攻擊，以至于最終演進出sqlmap這樣的神器存在。

后來的fastjson刷新了我的認知，這個框架也算是對互聯網安全概念的一種推動。連不懂技術的老板，都知道fastjson快的要命，作為程序員安全理念就得到了一次提升。

為什么對sql注入情有獨鐘？因為開發人員和SQL打交道的地方太多了。甚至有的專門開發報表的同學，寫的SQL行數，比寫的代碼行數還多！

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

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

當然在這方面，PHP的貢獻最大，Java甘拜下風。

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

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

MyBatis依然存在SQL注入

使用Mybatis的同學，第一個接觸的概念，就是#和$的區別。這兩個符號非常的像Shell中的魔幻符號，但好在只有兩種情況。

• #  代表的是使用sql預編譯方式，安全可靠

• $ 代表著使用的是拼接方式，有SQL注入的風險

比如下面這個xml配置，就是一個絕對安全的寫法。因為整個#{id}會被替換成?。

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

但可惜的是，有些場景，并不能使用預編譯方式（或者你僅僅是不知道或者懶）。像一些代碼重構，把表名/列名/排序等字段，動態傳入的時候，不可避免的就需要SQL拼接的方式，SQL注入依然有搞頭。

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

下面是兩句Like模糊查詢的寫法，實際測試會發現，使用#竟然不好使了，會報錯，需要使用sql拼接的$。問題由此發生。

SELECT * FROM order WHERE name like '%#{name}%'  //會報語法錯
SELECT * FROM order WHERE name like '%${name}%'  //可以運行

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

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

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

in (#{tag}) //報錯
in (${tag}) //可以運行

既然幾個字符就可以運行，當然沒人選擇下面復雜的寫法。

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

還有order by，也千萬不要掉以輕心，一不小心就會萬劫不復。

SELECT * FROM order order by createDate #{sortType} //報錯
SELECT * FROM order order by createDate ${sortType} //正常

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

總結

SQL注入在2021年，依然存在，只不過門檻提高了。現在SQL注入減少，都是框架的功勞，和程序員的水平沒半毛關系。sql拼接的情況永遠不會消失，因為這是最快捷簡單的方式，會讓人欲罷不能。無數的外包項目，十幾年躺尸不動的系統比比皆是，寄希望于在框架層全部消滅SQL注入，是一個夢想。

因為它的對手，是人性的懶惰。誰也無法戰勝它。

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