# 前言 最近我在整理安全漏洞相關問題，準備在公司做一次分享。恰好，這段時間團隊發現了一個sql注入漏洞：在一個公共的分頁功能中，排序欄位作為入參，前端頁面可以自定義。在分頁sql的`mybatis` `mapper.xml`中，`order by`欄位後面使用$符號動態接收計算後的排序引數，這樣可以實現動態排序的功能。 但是，如果入參傳入： ```sql id; select 1 -- ``` 最終執行的sql會變成： ```sql select * from test1 order by id; select 1 -- limit 1,20 ``` `--`會把後面的`limit`語句註釋掉，導致分頁條件失效，返回了所有資料。攻擊者可以通過這個漏洞一次性獲取所有資料。 動態排序這個功能原本的想法是好的，但是卻有`sql注入的風險`。值得慶幸的是，這次我們及時發現了問題，並且及時解決了，沒有造成什麼損失。 但是，幾年前在老東家的時候，就沒那麼幸運了。 **一次sql注入直接把我們支付服務搞掛了。** # 1. 還原事故現場 有一天運營小姐姐跑過來跟我說，有很多使用者支付不了。這個支付服務是一個老系統，轉手了3個人了，一直很穩定沒有出過啥問題。 我二話不說開始定位問題了，先看伺服器日誌，發現了很多報資料庫連線過多的異常。因為支付功能太重要了，當時為了保證支付功能快速恢復，先找運維把支付服務2個節點重啟了。 5分鐘後暫時恢復了正常。 我再繼續定位原因，據我當時的經驗判斷一般出現數據庫連線過多，可能是因為連線`忘了關閉`導致。但是仔細排查程式碼沒有發現問題，我們當時用的資料庫連線池，它會自動回收空閒連線的，`排除了這種可能`。 過了會兒，又有一個節點出現了資料庫連線過多的問題。 但此時，還沒查到原因，逼於無奈，只能讓運維再重啟服務，不過這次把資料庫`最大連線數調大`了，預設是100，我們當時設定的500，後面調成了1000。（其實現在大部分公司會將這個引數設定成`1000`） 使用命令： ```sql set GLOBAL 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. 其中`;`前面的查詢語句先執行了。 2. 由於`--`後面的語句會被註釋，接下來只會執行鎖表語句，把表鎖住。 4. 正常業務請求從資料庫連線池成功獲取連線後，需要操作表的時候，嘗試獲取表鎖，但一直獲取不到，直到超時。注意，這裡可能會累計大量的資料庫連線被佔用，沒有及時歸還。 5. 資料庫連線池不夠用，沒有空閒連線。 6. 新的業務請求從資料庫連線池獲取不到連線，報資料庫連線過多異常。 **sql注入導致資料庫連線過多問題，最根本的原因是長時間鎖表。** # 3.預編譯為什麼能防sql注入？ `preparestatement`預編譯機制會在sql語句執行前，對其進行語法分析、編譯和優化，其中引數位置使用佔位符`?`代替了。 當真正執行時，傳過來的引數會被看作是一個純文字，不會重新編譯，不會被當做sql指令。 這樣，即使入參傳入sql注入指令如： ```sql id; select 1 -- ``` 最終執行的sql會變成： ```sql select * from test1 order by 'id; select 1 --' limit 1,20 ``` 這樣就不會出現sql注入問題了。 # 4.預編譯就一定安全？ 不知道你在查詢資料時有沒有用過like語句，比如：查詢名字中帶有“蘇”字的使用者，就可能會用類似這樣的語句查詢： ```sql select * from user where name like '%蘇%'; ``` 正常情況下是沒有問題的。 但有些場景下要求傳入的條件是必填的，比如：name是必填的，如果注入了：`%`，最後執行的sql會變成這樣的： ```sql select * from user where name like '%%%'; ``` 這種情況預編譯機制是正常通過的，但sql的執行結果不會返回包含`%`的使用者，而是返回了所有使用者。 name欄位必填變得沒啥用了，攻擊者同樣可以獲取使用者表所有資料。 為什麼會出現這個問題呢？ `%`在mysql中是關鍵字，如果使用`like '%%%'`，該like條件會失效。 如何解決呢？ 需要對`%`進行轉義：`/%`。 轉義後的sql變成： ```sql select * from user where name like '%/%%'; ``` 只會返回包含`%`的使用者。 # 5.有些特殊的場景怎麼辦？ 在java中如果使用`mybatis`作為持久化框架，在`mapper.xml`檔案中，如果入參使用`#`傳值，會使用預編譯機制。 一般我們是這樣用的： ```sql ``` 絕大多數情況下，鼓勵大家使用`#`這種方式傳參，更安全，效率更高。 但是有時有些特殊情況，比如： ```sql ``` sortString欄位的內容是一個方法中動態計算出來的，這種情況是沒法用`#`，代替`$`的，這樣程式會報錯。 使用`$`的情況就有sql注入的風險。 那麼這種情況該怎辦呢？ 1. 自己寫個util工具過濾掉所有的注入關鍵字，動態計算時呼叫該工具。 2. 如果資料來源用的阿里的druid的話，可以開啟filter中的wall（防火牆），它包含了防止sql注入的功能。但是有個問題，就是它預設不允許多語句同時操作，對批量更新操作也會攔截，這就需要我們自定義filter了。 # 6.表資訊是如何洩露的？ 有些細心的同學，可能會提出一個問題：在上面鎖表的例子中，攻擊者是如何拿到表資訊的？ ### 方法1：盲猜 就是攻擊者根據常識猜測可能存在的表名稱。 假設我們有這樣的查詢條件： ```sql select * from t_order where id = ${id}; ``` 傳入引數：`-1;select * from user` 最終執行sql變成： ```sql select * from t_order where id = -1;select * from user; ``` 如果該sql有資料返回，說明user表存在，被猜中了。 建議表名不要起得過於簡單，可以帶上適當的字首，比如：t_user。 這樣可以增加盲猜的難度。 ### 方法2：通過系統表 其實mysql有些系統表，可以查到我們自定義的資料庫和表的資訊。 假設我們還是以這條sql為例： ```sql select code,name from t_order where id = ${id}; ``` 第一步，獲取資料庫和賬號名。 傳參為：`-1 union select database(),user()#` 最終執行sql變成： ```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變成： ```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. 核心資料洩露 大部分攻擊者的目的是為了賺錢，說白了就是獲取到有價值的資訊拿出去賣錢，比如：使用者賬號、密碼、手機號、身份證資訊、銀行卡號、地址等敏感資訊。 他們可以注入類似這樣的語句： ```sql -1; select * from user;-- ``` 就能輕鬆把使用者表中所有資訊都獲取到。 所以，建議大家對這些敏感資訊加密儲存，可以使用`AES`對稱加密。 #### 2. 刪庫跑路 也不乏有些攻擊者不按常理出牌，sql注入後直接把系統的表或者資料庫都刪了。 他們可以注入類似這樣的語句： ```sql -1; delete from user;-- ``` 以上語句會刪掉user表中所有資料。 ```sql -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. 把系統搞掛 有些攻擊者甚至可以直接把我們的服務搞掛了，在老東家的時候就是這種情況。 他們可以注入類似這樣的語句： ```sql -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大廠的前輩交流和