臥槽,sql注入竟然把我們的系統搞掛了

蘇三說技術發表於2021-02-15

前言

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

但是,如果入參傳入:

id; select 1 --

最終執行的sql會變成:

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

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

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

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

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

1. 還原事故現場

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

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

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

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

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

但此時,還沒查到原因,逼於無奈,只能讓運維再重啟服務,不過這次把資料庫最大連線數調大了,預設是100,我們當時設定的500,後面調成了1000。(其實現在大部分公司會將這個引數設定成1000

使用命令:

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. 其中;前面的查詢語句先執行了。
  3. 由於--後面的語句會被註釋,接下來只會執行鎖表語句,把表鎖住。
  4. 正常業務請求從資料庫連線池成功獲取連線後,需要操作表的時候,嘗試獲取表鎖,但一直獲取不到,直到超時。注意,這裡可能會累計大量的資料庫連線被佔用,沒有及時歸還。
  5. 資料庫連線池不夠用,沒有空閒連線。
  6. 新的業務請求從資料庫連線池獲取不到連線,報資料庫連線過多異常。

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

3.預編譯為什麼能防sql注入?

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

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

這樣,即使入參傳入sql注入指令如:

id; select 1 --

最終執行的sql會變成:

select * from test1 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 * from user 
   <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. 使用其他手段處理

對於不能使用預編譯傳參時,要麼開啟druidfilter防火牆,要麼自己寫程式碼邏輯過濾掉所有可能的注入關鍵字。

最後說一句(求關注,別白嫖我)

如果這篇文章對您有所幫助,或者有所啟發的話,幫忙關注一下,您的支援是我堅持寫作最大的動力。

求一鍵三連:點贊、轉發、在看。

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

相關文章