SQL注入竟然把我們的系統(tǒng)搞掛了
本文轉(zhuǎn)載自微信公眾號(hào)「蘇三說(shuō)技術(shù)」，作者因?yàn)闊釔?ài)所以堅(jiān)持ing。轉(zhuǎn)載本文請(qǐng)聯(lián)系蘇三說(shuō)技術(shù)公眾號(hào)。
前言
最近我在整理安全漏洞相關(guān)問(wèn)題，準(zhǔn)備在公司做一次分享。恰好，這段時(shí)間團(tuán)隊(duì)發(fā)現(xiàn)了一個(gè)sql注入漏洞：在一個(gè)公共的分頁(yè)功能中，排序字段作為入?yún)ⅲ岸隧?yè)面可以自定義。在分頁(yè)sql的mybatis mapper.xml中，order by字段后面使用$符號(hào)動(dòng)態(tài)接收計(jì)算后的排序參數(shù)，這樣可以實(shí)現(xiàn)動(dòng)態(tài)排序的功能。
但是，如果入?yún)魅耄?/p>
- id; select 1 --
最終執(zhí)行的sql會(huì)變成：
- select * from user order by id; select 1 -- limit 1,20
--會(huì)把后面的limit語(yǔ)句注釋掉，導(dǎo)致分頁(yè)條件失效，返回了所有數(shù)據(jù)。攻擊者可以通過(guò)這個(gè)漏洞一次性獲取所有數(shù)據(jù)。
動(dòng)態(tài)排序這個(gè)功能原本的想法是好的，但是卻有sql注入的風(fēng)險(xiǎn)。值得慶幸的是，這次我們及時(shí)發(fā)現(xiàn)了問(wèn)題，并且及時(shí)解決了，沒(méi)有造成什么損失。
但是，幾年前在老東家的時(shí)候，就沒(méi)那么幸運(yùn)了。
一次sql注入直接把我們支付服務(wù)搞掛了。
1. 還原事故現(xiàn)場(chǎng)
有一天運(yùn)營(yíng)小姐姐跑過(guò)來(lái)跟我說(shuō)，有很多用戶(hù)支付不了。這個(gè)支付服務(wù)是一個(gè)老系統(tǒng)，轉(zhuǎn)手了3個(gè)人了，一直很穩(wěn)定沒(méi)有出過(guò)啥問(wèn)題。
我二話(huà)不說(shuō)開(kāi)始定位問(wèn)題了，先看服務(wù)器日志，發(fā)現(xiàn)了很多報(bào)數(shù)據(jù)庫(kù)連接過(guò)多的異常。因?yàn)橹Ц豆δ芴匾耍?dāng)時(shí)為了保證支付功能快速恢復(fù)，先找運(yùn)維把支付服務(wù)2個(gè)節(jié)點(diǎn)重啟了。
5分鐘后暫時(shí)恢復(fù)了正常。
我再繼續(xù)定位原因，據(jù)我當(dāng)時(shí)的經(jīng)驗(yàn)判斷一般出現(xiàn)數(shù)據(jù)庫(kù)連接過(guò)多，可能是因?yàn)檫B接忘了關(guān)閉導(dǎo)致。但是仔細(xì)排查代碼沒(méi)有發(fā)現(xiàn)問(wèn)題，我們當(dāng)時(shí)用的數(shù)據(jù)庫(kù)連接池，它會(huì)自動(dòng)回收空閑連接的，排除了這種可能。
過(guò)了會(huì)兒，又有一個(gè)節(jié)點(diǎn)出現(xiàn)了數(shù)據(jù)庫(kù)連接過(guò)多的問(wèn)題。
但此時(shí)，還沒(méi)查到原因，逼于無(wú)奈，只能讓運(yùn)維再重啟服務(wù)，不過(guò)這次把數(shù)據(jù)庫(kù)最大連接數(shù)調(diào)大了，默認(rèn)是100，我們當(dāng)時(shí)設(shè)置的500，后面調(diào)成了1000。(其實(shí)現(xiàn)在大部分公司會(huì)將這個(gè)參數(shù)設(shè)置成1000)
使用命令：
- set GLOBAL max_connections=500;
能及時(shí)生效，不需要重啟mysql服務(wù)。
這次給我爭(zhēng)取了更多的時(shí)間，找dba幫忙一起排查原因。
使用show processlist;命令查看當(dāng)前線(xiàn)程執(zhí)行情況：
還可以查看當(dāng)前的連接狀態(tài)幫助識(shí)別出有問(wèn)題的查詢(xún)語(yǔ)句。(需要特別說(shuō)明的是上圖只是我給的一個(gè)例子，線(xiàn)上真實(shí)的結(jié)果不是這樣的)
- id 線(xiàn)程id
- User 執(zhí)行sql的賬號(hào)
- Host 執(zhí)行sql的數(shù)據(jù)庫(kù)的ip和端號(hào)
- db 數(shù)據(jù)庫(kù)名稱(chēng)
- Command 執(zhí)行命令，包括：Daemon、Query、Sleep等。
- Time 執(zhí)行sql所消耗的時(shí)間
- State 執(zhí)行狀態(tài)
- info 執(zhí)行信息，里面可能包含sql信息。
果然，發(fā)現(xiàn)了一條不尋常的查詢(xún)sql，執(zhí)行了差不多1個(gè)小時(shí)還沒(méi)有執(zhí)行完。
dba把那條sql復(fù)制出來(lái)，發(fā)給我了。然后kill -9 殺掉了那條執(zhí)行耗時(shí)非常長(zhǎng)的sql線(xiàn)程。
后面，數(shù)據(jù)庫(kù)連接過(guò)多的問(wèn)題就沒(méi)再出現(xiàn)了。
我拿到那條sql仔細(xì)分析了一下，發(fā)現(xiàn)一條訂單查詢(xún)語(yǔ)句被攻擊者注入了很長(zhǎng)的一段sql，肯定是高手寫(xiě)的，有些語(yǔ)法我都沒(méi)見(jiàn)過(guò)。
但可以確認(rèn)無(wú)誤，被人sql注入了。
通過(guò)那條sql中的信息，我很快找到了相關(guān)代碼，查詢(xún)數(shù)據(jù)時(shí)入?yún)⒕谷挥玫腟tatment，而非PrepareStatement預(yù)編譯機(jī)制。
知道原因就好處理了，將查詢(xún)數(shù)據(jù)的地方改成preparestatement預(yù)編譯機(jī)制后問(wèn)題得以最終解決。
2.為什么會(huì)導(dǎo)致數(shù)據(jù)庫(kù)連接過(guò)多?
我相信很多同學(xué)看到這里，都會(huì)有一個(gè)疑問(wèn)：sql注入為何會(huì)導(dǎo)致數(shù)據(jù)庫(kù)連接過(guò)多?
我下面用一張圖，給大家解釋一下：
- 攻擊者sql注入了類(lèi)似這樣的參數(shù)：-1;鎖表語(yǔ)句--。
- 其中;前面的查詢(xún)語(yǔ)句先執(zhí)行了。
- 由于--后面的語(yǔ)句會(huì)被注釋?zhuān)酉聛?lái)只會(huì)執(zhí)行鎖表語(yǔ)句，把表鎖住。
- 正常業(yè)務(wù)請(qǐng)求從數(shù)據(jù)庫(kù)連接池成功獲取連接后，需要操作表的時(shí)候，嘗試獲取表鎖，但一直獲取不到，直到超時(shí)。注意，這里可能會(huì)累計(jì)大量的數(shù)據(jù)庫(kù)連接被占用，沒(méi)有及時(shí)歸還。
- 數(shù)據(jù)庫(kù)連接池不夠用，沒(méi)有空閑連接。
- 新的業(yè)務(wù)請(qǐng)求從數(shù)據(jù)庫(kù)連接池獲取不到連接，報(bào)數(shù)據(jù)庫(kù)連接過(guò)多異常。
sql注入導(dǎo)致數(shù)據(jù)庫(kù)連接過(guò)多問(wèn)題，最根本的原因是長(zhǎng)時(shí)間鎖表。
3.預(yù)編譯為什么能防sql注入?
preparestatement預(yù)編譯機(jī)制會(huì)在sql語(yǔ)句執(zhí)行前，對(duì)其進(jìn)行語(yǔ)法分析、編譯和優(yōu)化，其中參數(shù)位置使用占位符?代替了。
當(dāng)真正運(yùn)行時(shí)，傳過(guò)來(lái)的參數(shù)會(huì)被看作是一個(gè)純文本，不會(huì)重新編譯，不會(huì)被當(dāng)做sql指令。
這樣，即使入?yún)魅雜ql注入指令如：
- id; select 1 --
最終執(zhí)行的sql會(huì)變成：
- select * from user order by 'id; select 1 --' limit 1,20
這樣就不會(huì)出現(xiàn)sql注入問(wèn)題了。
4.預(yù)編譯就一定安全?
不知道你在查詢(xún)數(shù)據(jù)時(shí)有沒(méi)有用過(guò)like語(yǔ)句，比如：查詢(xún)名字中帶有“蘇”字的用戶(hù)，就可能會(huì)用類(lèi)似這樣的語(yǔ)句查詢(xún)：
- select * from user where name like '%蘇%';
正常情況下是沒(méi)有問(wèn)題的。
但有些場(chǎng)景下要求傳入的條件是必填的，比如：name是必填的，如果注入了：%，最后執(zhí)行的sql會(huì)變成這樣的：
- select * from user where name like '%%%';
這種情況預(yù)編譯機(jī)制是正常通過(guò)的，但sql的執(zhí)行結(jié)果不會(huì)返回包含%的用戶(hù)，而是返回了所有用戶(hù)。
name字段必填變得沒(méi)啥用了，攻擊者同樣可以獲取用戶(hù)表所有數(shù)據(jù)。
為什么會(huì)出現(xiàn)這個(gè)問(wèn)題呢?
%在mysql中是關(guān)鍵字，如果使用like '%%%'，該like條件會(huì)失效。
如何解決呢?
需要對(duì)%進(jìn)行轉(zhuǎn)義：/%。
轉(zhuǎn)義后的sql變成：
- select * from user where name like '%/%%';
只會(huì)返回包含%的用戶(hù)。
5.有些特殊的場(chǎng)景怎么辦?
在java中如果使用mybatis作為持久化框架，在mapper.xml文件中，如果入?yún)⑹褂?傳值，會(huì)使用預(yù)編譯機(jī)制。
一般我們是這樣用的：
- <sql id="query">
- select * from user
- <where>
- name = #{name}
- </where>
- </sql>
絕大多數(shù)情況下，鼓勵(lì)大家使用#這種方式傳參，更安全，效率更高。
但是有時(shí)有些特殊情況，比如：
- <sql id="orderBy">
- order by ${sortString}
- </sql>
sortString字段的內(nèi)容是一個(gè)方法中動(dòng)態(tài)計(jì)算出來(lái)的，這種情況是沒(méi)法用#，代替$的，這樣程序會(huì)報(bào)錯(cuò)。
使用$的情況就有sql注入的風(fēng)險(xiǎn)。
那么這種情況該怎辦呢?
- 自己寫(xiě)個(gè)util工具過(guò)濾掉所有的注入關(guān)鍵字，動(dòng)態(tài)計(jì)算時(shí)調(diào)用該工具。
- 如果數(shù)據(jù)源用的阿里的druid的話(huà)，可以開(kāi)啟filter中的wall(防火墻)，它包含了防止sql注入的功能。但是有個(gè)問(wèn)題，就是它默認(rèn)不允許多語(yǔ)句同時(shí)操作，對(duì)批量更新操作也會(huì)攔截，這就需要我們自定義filter了。
6.表信息是如何泄露的?
有些細(xì)心的同學(xué)，可能會(huì)提出一個(gè)問(wèn)題：在上面鎖表的例子中，攻擊者是如何拿到表信息的?
方法1：盲猜
就是攻擊者根據(jù)常識(shí)猜測(cè)可能存在的表名稱(chēng)。
假設(shè)我們有這樣的查詢(xún)條件：
- select * from t_order where id = ${id};
傳入?yún)?shù)：-1;select * from user
最終執(zhí)行sql變成：
- select * from t_order where id = -1; select * from user;
如果該sql有數(shù)據(jù)返回，說(shuō)明user表存在，被猜中了。
建議表名不要起得過(guò)于簡(jiǎn)單，可以帶上適當(dāng)?shù)那熬Y，比如：t_user。這樣可以增加盲猜的難度。
方法2：通過(guò)系統(tǒng)表
其實(shí)mysql有些系統(tǒng)表，可以查到我們自定義的數(shù)據(jù)庫(kù)和表的信息。
假設(shè)我們還是以這條sql為例：
- select code,name from t_order where id = ${id};
第一步，獲取數(shù)據(jù)庫(kù)和賬號(hào)名。
傳參為：-1 union select database(),user()#
最終執(zhí)行sql變成：
- select code,name from t_order where id = -1 union select database(),user()#
會(huì)返回當(dāng)前 數(shù)據(jù)庫(kù)名稱(chēng)：sue 和 賬號(hào)名稱(chēng)：root@localhost。
第二步，獲取表名。
傳參改成：-1 union select table_name,table_schema from information_schema.tables where table_schema='sue'#最終執(zhí)行sql變成：
- select code,name from t_order where id = -1 union select table_name,table_schema from information_schema.tables where table_schema='sue'#
會(huì)返回?cái)?shù)據(jù)庫(kù)sue下面所有表名。
建議在生成環(huán)境程序訪問(wèn)的數(shù)據(jù)庫(kù)賬號(hào)，要跟管理員賬號(hào)分開(kāi)，一定要控制權(quán)限，不能訪問(wèn)系統(tǒng)表。
7.sql注入到底有哪些危害?
1. 核心數(shù)據(jù)泄露
大部分攻擊者的目的是為了賺錢(qián)，說(shuō)白了就是獲取到有價(jià)值的信息拿出去賣(mài)錢(qián)，比如：用戶(hù)賬號(hào)、密碼、手機(jī)號(hào)、身份證信息、銀行卡號(hào)、地址等敏感信息。
他們可以注入類(lèi)似這樣的語(yǔ)句：
- -1; select * from user; --
就能輕松把用戶(hù)表中所有信息都獲取到。
所以，建議大家對(duì)這些敏感信息加密存儲(chǔ)，可以使用AES對(duì)稱(chēng)加密。
2. 刪庫(kù)跑路
也不乏有些攻擊者不按常理出牌，sql注入后直接把系統(tǒng)的表或者數(shù)據(jù)庫(kù)都刪了。
他們可以注入類(lèi)似這樣的語(yǔ)句：
- -1; delete from user; --
以上語(yǔ)句會(huì)刪掉user表中所有數(shù)據(jù)。
- -1; drop database test; --
以上語(yǔ)句會(huì)把整個(gè)test數(shù)據(jù)庫(kù)所有內(nèi)容都刪掉。
正常情況下，我們需要控制線(xiàn)上賬號(hào)的權(quán)限，只允許DML(data manipulation language)數(shù)據(jù)操縱語(yǔ)言語(yǔ)句，包括：select、update、insert、delete等。
不允許DDL(data definition language)數(shù)據(jù)庫(kù)定義語(yǔ)言語(yǔ)句，包含：create、alter、drop等。
也不允許DCL(Data Control Language)數(shù)據(jù)庫(kù)控制語(yǔ)言語(yǔ)句，包含：grant,deny,revoke等。
DDL和DCL語(yǔ)句只有dba的管理員賬號(hào)才能操作。
順便提一句：如果被刪表或刪庫(kù)了，其實(shí)還有補(bǔ)救措施，就是從備份文件中恢復(fù)，可能只會(huì)丟失少量實(shí)時(shí)的數(shù)據(jù)，所以一定有備份機(jī)制。
3. 把系統(tǒng)搞掛
有些攻擊者甚至可以直接把我們的服務(wù)搞掛了，在老東家的時(shí)候就是這種情況。
他們可以注入類(lèi)似這樣的語(yǔ)句：
- -1;鎖表語(yǔ)句;--
把表長(zhǎng)時(shí)間鎖住后，可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)連接耗盡。
這時(shí)，我們需要對(duì)數(shù)據(jù)庫(kù)線(xiàn)程做監(jiān)控，如果某條sql執(zhí)行時(shí)間太長(zhǎng)，要郵件預(yù)警。此外，合理設(shè)置數(shù)據(jù)庫(kù)連接的超時(shí)時(shí)間，也能稍微緩解一下這類(lèi)問(wèn)題。
從上面三個(gè)方面，能看出sql注入問(wèn)題的危害真的挺大的，我們一定要避免該類(lèi)問(wèn)題的發(fā)生，不要存著僥幸的心理。如果遇到一些不按常理出票的攻擊者，一旦被攻擊了，你可能會(huì)損失慘重。
8. 如何防止sql注入?
1. 使用預(yù)編譯機(jī)制
盡量用預(yù)編譯機(jī)制，少用字符串拼接的方式傳參，它是sql注入問(wèn)題的根源。
2. 要對(duì)特殊字符轉(zhuǎn)義
有些特殊字符，比如：%作為like語(yǔ)句中的參數(shù)時(shí)，要對(duì)其進(jìn)行轉(zhuǎn)義處理。
3. 要捕獲異常
需要對(duì)所有的異常情況進(jìn)行捕獲，切記接口直接返回異常信息，因?yàn)橛行┊惓Ｐ畔⒅邪藄ql信息，包括：庫(kù)名，表名，字段名等。攻擊者拿著這些信息，就能通過(guò)sql注入隨心所欲的攻擊你的數(shù)據(jù)庫(kù)了。目前比較主流的做法是，有個(gè)專(zhuān)門(mén)的網(wǎng)關(guān)服務(wù)，它統(tǒng)一暴露對(duì)外接口。用戶(hù)請(qǐng)求接口時(shí)先經(jīng)過(guò)它，再由它將請(qǐng)求轉(zhuǎn)發(fā)給業(yè)務(wù)服務(wù)。這樣做的好處是：能統(tǒng)一封裝返回?cái)?shù)據(jù)的返回體，并且如果出現(xiàn)異常，能返回統(tǒng)一的異常信息，隱藏敏感信息。此外還能做限流和權(quán)限控制。
4. 使用代碼檢測(cè)工具
使用sqlMap等代碼檢測(cè)工具，它能檢測(cè)sql注入漏洞。
5. 要有監(jiān)控
需要對(duì)數(shù)據(jù)庫(kù)sql的執(zhí)行情況進(jìn)行監(jiān)控，有異常情況，及時(shí)郵件或短信提醒。
6. 數(shù)據(jù)庫(kù)賬號(hào)需控制權(quán)限
對(duì)生產(chǎn)環(huán)境的數(shù)據(jù)庫(kù)建立單獨(dú)的賬號(hào)，只分配DML相關(guān)權(quán)限，且不能訪問(wèn)系統(tǒng)表。切勿在程序中直接使用管理員賬號(hào)。
7. 代碼review
建立代碼review機(jī)制，能找出部分隱藏的問(wèn)題，提升代碼質(zhì)量。
8. 使用其他手段處理
對(duì)于不能使用預(yù)編譯傳參時(shí)，要么開(kāi)啟druid的filter防火墻，要么自己寫(xiě)代碼邏輯過(guò)濾掉所有可能的注入關(guān)鍵字。
