很長一段時間，我認為后端開發，在安全性方面最容易出問題的地方就在于sql注入。通過 where 1=1這種魔幻的SQL寫法，就可以很容易的對一個存在問題的系統進行攻擊，以至于最終演進出sqlmap這樣的神器存在。
后來的fastjson刷新了我的認知，這個框架也算是對互聯網安全概念的一種推動。連不懂技術的老板，都知道fastjson快的要命，作為程序員安全理念就得到了一次提升。
推薦（免費）：sql
為什么對sql注入情有獨鐘？因為開發人員和SQL打交道的地方太多了。甚至有的專門開發報表的同學，寫的SQL行數，比寫的代碼行數還多！
問題是。很久很久之前，早在10年前，就有人在喊SQL注入已經死掉了，但時至今日，依然有一大批的SQL注入教程和SQL注入的案例。
SQL注入是漏洞之王，這可不是吹的。
SQL注入流行的原因，就是開發人員對自己太自信了，或者使用的工具太原始了，沒有經過框架層進行一次過濾。如果你用了Java界的mybatis或者JPA，發生SQL注入的可能性就變的非常的低。現在PHP也有了類似于thinkphp一樣的框架，代表著能搞的SQL注入漏洞已經越來越少了。
但不代表著沒有，只是門檻提高了。我們以MyBatis為例，看一下到底還能不能發生SQL注入。
MyBatis依然存在SQL注入
使用Mybatis的同學，第一個接觸的概念，就是#和$的區別。這兩個符號非常的像Shell中的魔幻符號，但好在只有兩種情況。
-
# ?代表的是使用sql預編譯方式，安全可靠
-
$ 代表著使用的是拼接方式，有SQL注入的風險
比如下面這個xml配置，就是一個絕對安全的寫法。因為整個#{id}會被替換成?。
<select> ??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> #{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注入，是一個夢想。
因為它的對手，是人性的懶惰。誰也無法戰勝它。
