記一次系統被sql注入搞掛的慘痛經歷

前言

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

但是，如果入參傳入：

id; select 1 --

最終執行的sql會變成：

select * from user order by id; select 1 -- limit 1,20

–會把后面的limit陳述句注釋掉，導致分頁條件失效，回傳了所有資料，攻擊者可以通過這個漏洞一次性獲取所有資料，

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

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

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

1. 還原事故現場

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

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

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

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

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

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

使用命令：

setGLOBAL max_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預編譯機制后問題得以最終解決，

2.為什么會導致資料庫連接過多？

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

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

1. 攻擊者sql注入了類似這樣的引數：-1;鎖表陳述句--，
2. 其中;前面的查詢陳述句先執行了，
3. 由于--后面的陳述句會被注釋，接下來只會執行鎖表陳述句，把表鎖住，
4. 正常業務請求從資料庫連接池成功獲取連接后，需要操作表的時候，嘗試獲取表鎖，但一直獲取不到，直到超時，注意，這里可能會累計大量的資料庫連接被占用，沒有及時歸還，
5. 資料庫連接池不夠用，沒有空閑連接，
   新的業務請求從資料庫連接池獲取不到連接，報資料庫連接過多例外，

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

3.預編譯為什么能防sql注入？

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

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

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

id; select 1 --

最終執行的sql會變成：

select * from user order by 'id; select 1 --' limit 1,20

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

4.預編譯就一定安全？

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

select * from user where name like '%蘇%';

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

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

select * from user where name like ‘%%%’;
這種情況預編譯機制是正常通過的，但sql的執行結果不會回傳包含%的用戶，而是回傳了所有用戶，

name欄位必填變得沒啥用了，攻擊者同樣可以獲取用戶表所有資料，

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

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

如何解決呢？

需要對%進行轉義：\%，

轉義后的sql變成：

select * from user where name like '%\%%';

只會回傳包含%的用戶，

5.有些特殊的場景怎么辦？

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

一般我們是這樣用的：

<sql id="query">
   select * fromuser
   <where>
     name = #{name}
   </where>
</sql>

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

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

<sql id="orderBy">
   order by ${sortString}
</sql>

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

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

那么這種情況該怎辦呢？

1. 自己寫個util工具過濾掉所有的注入關鍵字，動態計算時呼叫該工具，
2. 如果資料源用的阿里的druid的話，可以開啟filter中的wall（防火墻），它包含了防止sql注入的功能，但是有個問題，就是它默認不允許多陳述句同時操作，對批量更新操作也會攔截，這就需要我們自定義filter了，

6.表資訊是如何泄露的？

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

方法1：盲猜

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

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

select * from t_order where id = ${id};

傳入引數：-1;select * from user

最終執行sql變成：

select * from t_order where id = -1; select * from user;

如果該sql有資料回傳，說明user表存在，被猜中了，

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

方法2：通過系統表

其實mysql有些系統表，可以查到我們自定義的資料庫和表的資訊，

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

select code,name from t_order where id = ${id};

第一步，獲取資料庫和賬號名，

傳參為：-1 union select database(),user()#

最終執行sql變成：

select code,name from t_order where id = -1 union select database(),user()#

會回傳當前 資料庫名稱：sue 和 賬號名稱：root@localhost，

第二步，獲取表名，

傳參改成：-1 union select table_name,table_schema from information_schema.tables where table_schema='sue'#最終執行sql變成：

select code,name from t_order where id = -1 union select table_name,table_schema from information_schema.tables where table_schema='sue'#

會回傳資料庫sue下面所有表名，

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

7.sql注入到底有哪些危害？

1. 核心資料泄露

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

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

-1; select * from user; --

就能輕松把用戶表中所有資訊都獲取到，

所以，建議大家對這些敏感資訊加密存盤，可以使用AES對稱加密，

2. 刪庫跑路

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

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

-1; delete from user; --

以上陳述句會刪掉user表中所有資料，

-1; drop database test; --

以上陳述句會把整個test資料庫所有內容都刪掉，

正常情況下，我們需要控制線上賬號的權限，只允許DML（data manipulation language）資料操縱語言陳述句，包括：select、update、insert、delete等，

不允許DDL（data definition language）資料庫定義語言陳述句，包含：create、alter、drop等，

也不允許DCL（Data Control Language）資料庫控制語言陳述句，包含：grant,deny,revoke等，

DDL和DCL陳述句只有dba的管理員賬號才能操作，

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

3. 把系統搞掛

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

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

-1;鎖表陳述句;--

把表長時間鎖住后，可能會導致資料庫連接耗盡，

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

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

8. 如何防止sql注入？

1. 使用預編譯機制

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

2. 要對特殊字符轉義

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

3. 要捕獲例外

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

4. 使用代碼檢測工具

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

5. 要有監控

需要對資料庫sql的執行情況進行監控，有例外情況，及時郵件或短信提醒，

6. 資料庫賬號需控制權限

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

7. 代碼review

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

8. 使用其他手段處理

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

最后說一句(求關注，別白嫖我)

如果這篇文章對您有所幫助，或者有所啟發的話，幫忙掃描下發二維碼關注一下，您的支持是我堅持寫作最大的動力，

求一鍵三連：點贊、轉發、在看，

關注公眾號：【蘇三說技術】，在公眾號中回復：面試、代碼神器、開發手冊、時間管理有超贊的粉絲福利，另外回復：加群，可以跟很多BAT大廠的前輩交流和學習，