SQL注入竟然把我們的系統搞掛了，如何防止sql注入？

最近我在整理安全漏洞相關問題，準備在公司做一次分享。恰好，這段時間團隊發現了一個 sql 注入漏洞：在一個公共的分頁功能中，排序字段作為入參，前端頁面可以自定義。在分頁 sql 的 mybatis mapper.xml 中，order by 字段后面使用 $ 符號動態接收計算后的排序參數，這樣可以實現動態排序的功能。

但是，如果入參傳入：

id;select1--

最終執行的 sql 會變成：

ｓｅｌｅｃｔ*fromuserorderbyid;select1--limit1,20

--會把后面的 limit 語句注釋掉，導致分頁條件失效，返回了所有數據。攻擊者可以通過這個漏洞一次性獲取所有數據。

動態排序這個功能原本的想法是好的，但是卻有 sql 注入的風險。值得慶幸的是，這次我們及時發現了問題，并且及時解決了，沒有造成什么損失。

但是，幾年前在老東家的時候，就沒那么幸運了。

一次 sql 注入直接把我們支付服務搞掛了。

一、還原事故現場

有一天運營小姐姐跑過來跟我說，有很多用戶支付不了。這個支付服務是一個老系統，轉手了 3 個人了，一直很穩定沒有出過啥問題。

我二話不說開始定位問題了，先看服務器日志，發現了很多報數據庫連接過多的異常。因為支付功能太重要了，當時為了保證支付功能快速恢復，先找運維把支付服務 2 個節點重啟了。

5 分鐘后暫時恢復了正常。

我再繼續定位原因，據我當時的經驗判斷一般出現數據庫連接過多，可能是因為連接忘了關閉導致。但是仔細排查代碼沒有發現問題，我們當時用的數據庫連接池，它會自動回收空閑連接的，排除了這種可能。

過了會兒，又有一個節點出現了數據庫連接過多的問題。

但此時，還沒查到原因，逼于無奈，只能讓運維再重啟服務，不過這次把數據庫最大連接數調大了，默認是 100，我們當時設置的 500，后面調成了 1000。（其實現在大部分公司會將這個參數設置成 1000）

使用命令：

setGLOBALmax_connections=500;

能及時生效，不需要重啟 MySQL 服務。

這次給我爭取了更多的時間，找 dba 幫忙一起排查原因。

使用 show processlist；命令查看當前線程執行情況：

還可以查看當前的連接狀態幫助識別出有問題的查詢語句。（需要特別說明的是上圖只是我給的一個例子，線上真實的結果不是這樣的）

• id線程 id

• User 執行sql的賬號

• Host 執行 sql 的數據庫的 ip 和端號

• db 數據庫名稱

• Command 執行命令，包括：Daemon、Query、Sleep 等。

• Time 執行 sql 所消耗的時間

• State 執行狀態

• info 執行信息，里面可能包含 sql 信息。

果然，發現了一條不尋常的查詢sql，執行了差不多1個小時還沒有執行完。

dba 把那條 sql 復制出來，發給我了。然后 kill -9 殺掉了那條執行耗時非常長的 sql 線程。

后面，數據庫連接過多的問題就沒再出現了。

我拿到那條 sql 仔細分析了一下，發現一條訂單查詢語句被攻擊者注入了很長的一段 sql，肯定是高手寫的，有些語法我都沒見過。

但可以確認無誤，被人 sql 注入了。

通過那條 sql 中的信息，我很快找到了相關代碼，查詢數據時入參竟然用的 Statment，而非 PrepareStatement 預編譯機制。

知道原因就好處理了，將查詢數據的地方改成 preparestatement 預編譯機制后問題得以最終解決。

二、為什么會導致數據庫連接過多？

我相信很多同學看到這里，都會有一個疑問：sql 注入為何會導致數據庫連接過多？

我下面用一張圖，給大家解釋一下：

• 攻擊者 sql 注入了類似這樣的參數：-1;鎖表語句--。

• 其中，前面的查詢語句先執行了。

• 由于--后面的語句會被注釋，接下來只會執行鎖表語句，把表鎖住。

• 正常業務請求從數據庫連接池成功獲取連接后，需要操作表的時候，嘗試獲取表鎖，但一直獲取不到，直到超時。注意，這里可能會累計大量的數據庫連接被占用，沒有及時歸還。

• 數據庫連接池不夠用，沒有空閑連接。

• 新的業務請求從數據庫連接池獲取不到連接，報數據庫連接過多異常。

sql 注入導致數據庫連接過多問題，最根本的原因是長時間鎖表。

三、預編譯為什么能防 sql 注入？

preparestatement 預編譯機制會在 sql 語句執行前，對其進行語法分析、編譯和優化，其中參數位置使用占位符？代替了。

當真正運行時，傳過來的參數會被看作是一個純文本，不會重新編譯，不會被當做 sql 指令。

這樣，即使入參傳入 sql 注入指令如：

id;select1--

最終執行的 sql 會變成：

ｓｅｌｅｃｔ*fromuserorderby'id;select1--'limit1,20

這樣就不會出現 sql 注入問題了。

四、預編譯就一定安全？

不知道你在查詢數據時有沒有用過 like 語句，比如：查詢名字中帶有“蘇”字的用戶，就可能會用類似這樣的語句查詢：

ｓｅｌｅｃｔ*fromuserwherenamelike'%蘇%';

正常情況下是沒有問題的。

但有些場景下要求傳入的條件是必填的，比如：name 是必填的，如果注入了：%，最后執行的 sql 會變成這樣的：

ｓｅｌｅｃｔ*fromuserwherenamelike'%%%';

這種情況預編譯機制是正常通過的，但 sql 的執行結果不會返回包含%的用戶，而是返回了所有用戶。

name 字段必填變得沒啥用了，攻擊者同樣可以獲取用戶表所有數據。

為什么會出現這個問題呢？

% 在 mysql 中是關鍵字，如果使用 like '%%%'，該 like 條件會失效。

如何解決呢？

需要對 % 進行轉義：/%。

轉義后的 sql 變成：

ｓｅｌｅｃｔ*fromuserwherenamelike'%/%%';

只會返回包含%的用戶。

五、有些特殊的場景怎么辦？

在 java 中如果使用 mybatis 作為持久化框架，在 mapper.xml 文件中，如果入參使用 # 傳值，會使用預編譯機制。

一般我們是這樣用的：

<sqlid="query">ｓｅｌｅｃｔ*fromuser<where>name=#{name}</where></sql>

絕大多數情況下，鼓勵大家使用#這種方式傳參，更安全，效率更高。

但是有時有些特殊情況，比如：

<sqlid="orderBy">orderby${sortString}</sql>

sortString 字段的內容是一個方法中動態計算出來的，這種情況是沒法用#，代替$的，這樣程序會報錯。

使用 $ 的情況就有 sql 注入的風險。

那么這種情況該怎辦呢？

• 自己寫個 util 工具過濾掉所有的注入關鍵字，動態計算時調用該工具。

• 如果數據源用的阿里的 druid 的話，可以開啟 filter 中的 wall（防火墻），它包含了防止 sql 注入的功能。但是有個問題，就是它默認不允許多語句同時操作，對批量更新操作也會攔截，這就需要我們自定義 filter 了。

六、表信息是如何泄露的？

有些細心的同學，可能會提出一個問題：在上面鎖表的例子中，攻擊者是如何拿到表信息的？

方法1：盲猜

就是攻擊者根據常識猜測可能存在的表名稱。

假設我們有這樣的查詢條件：

ｓｅｌｅｃｔ*fromt_orderwhereid=${id};

傳入參數：-1;ｓｅｌｅｃｔ * from user

最終執行sql變成：

ｓｅｌｅｃｔ*fromt_orderwhereid=-1;ｓｅｌｅｃｔ*fromuser;

如果該sql有數據返回，說明user表存在，被猜中了。

建議表名不要起得過于簡單，可以帶上適當的前綴，比如：t_user。這樣可以增加盲猜的難度。

方法2：通過系統表

其實 mysql 有些系統表，可以查到我們自定義的數據庫和表的信息。

假設我們還是以這條 sql 為例：

selectcode,namefromt_orderwhereid=${id};

靠前步，獲取數據庫和賬號名。

傳參為：-1ｕｎｉｏｎｓｅｌｅｃｔ database(),user()#

最終執行sql變成：

selectcode,namefromt_orderwhereid=-1unionselectdatabase(),user()#

會返回當前數據庫名稱：sue和賬號名稱：root@localhost。

第二步，獲取表名。

傳參改成：-1ｕｎｉｏｎｓｅｌｅｃｔ table_name,table_schema from information_schema.tables where table_schema='sue'

#最終執行sql變成：

selectcode,namefromt_orderwhereid=-1unionselecttable_name,table_schemafrominformation_schema.tableswheretable_schema='sue'#

會返回數據庫sue下面所有表名。

建議在生成環境程序訪問的數據庫賬號，要跟管理員賬號分開，一定要控制權限，不能訪問系統表。

七、sql注入到底有哪些危害？

7.1 核心數據泄露

大部分攻擊者的目的是為了賺錢，說白了就是獲取到有價值的信息拿出去賣錢，比如：用戶賬號、密碼、手機號、***信息、銀行卡號、地址等敏感信息。

他們可以注入類似這樣的語句：

-1;ｓｅｌｅｃｔ*fromuser;--

就能輕松把用戶表中所有信息都獲取到。

所以，建議大家對這些敏感信息加密存儲，可以使用 AES 對稱加密。

7.2 刪庫跑路

也不乏有些攻擊者不按常理出牌，sql 注入后直接把系統的表或者數據庫都刪了。

他們可以注入類似這樣的語句：

-1;deletefromuser;--

以上語句會刪掉 user 表中所有數據。

-1;dropdatabasetest;--

以上語句會把整個 test 數據庫所有內容都刪掉。

正常情況下，我們需要控制線上賬號的權限，只允許 DML（data manipulation language）數據操縱語言語句，包括：ｓｅｌｅｃｔ、ｕｐｄａｔｅ、ｉｎｓｅｒｔ、ｄｅｌｅｔｅ 等。

不允許 DDL（data definition language）數據庫定義語言語句，包含：create、alter、ｄｒｏｐ 等。

也不允許 DCL（Data Control Language）數據庫控制語言語句，包含：ｇｒａｎｔ,deny,ｒｅｖｏｋｅ 等。

DDL 和 DCL 語句只有 dba 的管理員賬號才能操作。

順便提一句：如果被刪表或刪庫了，其實還有補救措施，就是從備份文件中恢復，可能只會丟失少量實時的數據，所以一定有備份機制。

7.3 把系統搞掛

有些攻擊者甚至可以直接把我們的服務搞掛了，在老東家的時候就是這種情況。

他們可以注入類似這樣的語句：

-1;鎖表語句;--

把表長時間鎖住后，可能會導致數據庫連接耗盡。

這時，我們需要對數據庫線程做監控，如果某條sql執行時間太長，要郵件預警。此外，合理設置數據庫連接的超時時間，也能稍微緩解一下這類問題。

從上面三個方面，能看出sql注入問題的危害真的挺大的，我們一定要避免該類問題的發生，不要存著僥幸的心理。如果遇到一些不按常理出票的攻擊者，一旦被攻擊了，你可能會損失慘重。

八、如何防止 sql 注入？

8.1 使用預編譯機制

盡量用預編譯機制，少用字符串拼接的方式傳參，它是sql注入問題的根源。

8.2 要對特殊字符轉義

有些特殊字符，比如：%作為like語句中的參數時，要對其進行轉義處理。

8.3 要捕獲異常

需要對所有的異常情況進行捕獲，切記接口直接返回異常信息，因為有些異常信息中包含了 sql 信息，包括：庫名，表名，字段名等。攻擊者拿著這些信息，就能通過 sql 注入隨心所欲的攻擊你的數據庫了。目前比較主流的做法是，有個專門的***服務，它統一暴露對外接口。用戶請求接口時先經過它，再由它將請求轉發給業務服務。這樣做的好處是：能統一封裝返回數據的返回體，并且如果出現異常，能返回統一的異常信息，隱藏敏感信息。此外還能做限流和權限控制。

8.4 使用代碼檢測工具

使用sqlMap等代碼檢測工具，它能檢測sql注入漏洞。

8.5 要有監控

需要對數據庫 sql 的執行情況進行監控，有異常情況，及時郵件或短信提醒。

8.6 數據庫賬號需控制權限

對生產環境的數據庫建立單獨的賬號，只分配DML相關權限，且不能訪問系統表。切勿在程序中直接使用管理員賬號。

8.7 代碼review

建立代碼review機制，能找出部分隱藏的問題，提升代碼質量。

8.8 使用其他手段處理

對于不能使用預編譯傳參時，要么開啟 druid 的 filter 防火墻，要么自己寫代碼邏輯過濾掉所有可能的注入關鍵字。