確定SQL注入死透了麼？

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

後來的fastjson刷新了我的認知，這個框架也算是對網路安全概念的一種推動。連不懂技術的老闆，都知道fastjson快的要命，身為程式設計師安全概念就得到了一次提升。

推薦（免費）：sql

#為什麼對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注入死透了麼？的詳細內容。更多資訊請關注PHP中文網其他相關文章！