前言

最近我在整理安全漏洞相關(guān)問題，準(zhǔn)備在公司做一次分享词疼。恰好俯树，這段時間團隊發(fā)現(xiàn)了一個sql注入漏洞：在一個公共的分頁功能中，排序字段作為入?yún)⒎〉粒岸隧撁婵梢宰远x许饿。在分頁sql的mybatis mapper.xml中，order by字段后面使用$符號動態(tài)接收計算后的排序參數(shù)舵盈，這樣可以實現(xiàn)動態(tài)排序的功能陋率。

但是球化，如果入?yún)魅耄?/p>

id; select 1 --

最終執(zhí)行的sql會變成：

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

--會把后面的limit語句注釋掉，導(dǎo)致分頁條件失效瓦糟，返回了所有數(shù)據(jù)筒愚。攻擊者可以通過這個漏洞一次性獲取所有數(shù)據(jù)。

動態(tài)排序這個功能原本的想法是好的菩浙，但是卻有sql注入的風(fēng)險巢掺。值得慶幸的是，這次我們及時發(fā)現(xiàn)了問題劲蜻，并且及時解決了陆淀，沒有造成什么損失。

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

一次sql注入直接把我們支付服務(wù)搞掛了坝初。

1. 還原事故現(xiàn)場

有一天運營小姐姐跑過來跟我說，有很多用戶支付不了钾军。這個支付服務(wù)是一個老系統(tǒng)鳄袍，轉(zhuǎn)手了3個人了，一直很穩(wěn)定沒有出過啥問題吏恭。

我二話不說開始定位問題了拗小，先看服務(wù)器日志，發(fā)現(xiàn)了很多報數(shù)據(jù)庫連接過多的異常樱哼。因為支付功能太重要了哀九，當(dāng)時為了保證支付功能快速恢復(fù)，先找運維把支付服務(wù)2個節(jié)點重啟了搅幅。

5分鐘后暫時恢復(fù)了正常阅束。

我再繼續(xù)定位原因，據(jù)我當(dāng)時的經(jīng)驗判斷一般出現(xiàn)數(shù)據(jù)庫連接過多茄唐，可能是因為連接忘了關(guān)閉導(dǎo)致息裸。但是仔細(xì)排查代碼沒有發(fā)現(xiàn)問題，我們當(dāng)時用的數(shù)據(jù)庫連接池沪编，它會自動回收空閑連接的呼盆，排除了這種可能。

過了會兒蚁廓，又有一個節(jié)點出現(xiàn)了數(shù)據(jù)庫連接過多的問題访圃。

但此時，還沒查到原因相嵌，逼于無奈腿时，只能讓運維再重啟服務(wù)克胳，不過這次把數(shù)據(jù)庫最大連接數(shù)調(diào)大了，默認(rèn)是100圈匆，我們當(dāng)時設(shè)置的500漠另，后面調(diào)成了1000。（其實現(xiàn)在大部分公司會將這個參數(shù)設(shè)置成1000）

使用命令：

set GLOBAL max_connections=500;

能及時生效跃赚，不需要重啟mysql服務(wù)笆搓。

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

他使用show processlist;命令查看當(dāng)前線程執(zhí)行情況：

image.png

還可以查看當(dāng)前的連接狀態(tài)幫助識別出有問題的查詢語句满败。

• id 線程id
• User 執(zhí)行sql的賬號
• Host 執(zhí)行sql的數(shù)據(jù)庫的ip和端號
• db 數(shù)據(jù)庫名稱
• Command 執(zhí)行命令，包括：Daemon叹括、Query算墨、Sleep等。
• Time 執(zhí)行sql所消耗的時間
• State 執(zhí)行狀態(tài)
• info 執(zhí)行信息汁雷，里面可能包含sql信息净嘀。

果然，發(fā)現(xiàn)了一條不尋常的查詢sql侠讯，執(zhí)行了差不多1個小時還沒有執(zhí)行完挖藏。

dba把那條sql復(fù)制出來，發(fā)給我了厢漩。然后kill -9 殺掉了那條執(zhí)行耗時非常長的sql線程膜眠。

后面，數(shù)據(jù)庫連接過多的問題就沒再出現(xiàn)了溜嗜。

我拿到那條sql仔細(xì)分析了一下宵膨，發(fā)現(xiàn)一條訂單查詢語句被攻擊者注入了很長的一段sql，肯定是高手寫的炸宵，有些語法我都沒見過辟躏。

但可以確認(rèn)無誤，被人sql注入了焙压。

通過那條sql中的信息鸿脓，我很快找到了相關(guān)代碼，查詢數(shù)據(jù)時入?yún)⒕谷挥玫?code>Statment涯曲，而非PrepareStatement預(yù)編譯機制野哭。

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

2.為什么會導(dǎo)致數(shù)據(jù)庫連接過多拨黔？

我相信很多同學(xué)看到這里，都會有一個疑問：sql注入為何會導(dǎo)致數(shù)據(jù)庫連接過多绰沥？

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

WX20210206-122254@2x.png

1. 攻擊者sql注入了類似這樣的參數(shù)：-1;鎖表語句--贺待。
2. 其中;前面的查詢語句先執(zhí)行了。
3. 由于--后面的語句會被注釋零截，接下來只會執(zhí)行鎖表語句麸塞，把表鎖住。
4. 正常業(yè)務(wù)請求從數(shù)據(jù)庫連接池成功獲取連接后涧衙，需要操作表的時候哪工，嘗試獲取表鎖，但一直獲取不到弧哎，直到超時雁比。注意，這里可能會累計大量的數(shù)據(jù)庫連接被占用撤嫩，沒有及時歸還偎捎。
5. 數(shù)據(jù)庫連接池不夠用，沒有空閑連接序攘。
6. 新的業(yè)務(wù)請求從數(shù)據(jù)庫連接池獲取不到連接茴她，報數(shù)據(jù)庫連接過多異常。

sql注入導(dǎo)致數(shù)據(jù)庫連接過多問題两踏，最根本的原因是長時間鎖表败京。

3.預(yù)編譯為什么能防sql注入？

preparestatement預(yù)編譯機制會在sql語句執(zhí)行前梦染，對其進(jìn)行語法分析、編譯和優(yōu)化朴皆，其中參數(shù)位置使用占位符?代替了帕识。

當(dāng)真正運行時，傳過來的參數(shù)會被看作是一個純文本遂铡，不會重新編譯肮疗，不會被當(dāng)做sql指令。

這樣扒接，即使入?yún)魅雜ql注入指令如：

id; select 1 --

最終執(zhí)行的sql會變成：

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

這樣就不會出現(xiàn)sql注入問題了伪货。

4.預(yù)編譯就一定安全？

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

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

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

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

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

這種情況預(yù)編譯機制是正常通過的矾利，但sql的執(zhí)行結(jié)果不會返回包含%的用戶姑裂，而是返回了所有用戶馋袜。

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

為什么會出現(xiàn)這個問題呢欣鳖？

%在mysql中是關(guān)鍵字，如果使用like '%%%'茴厉，該like條件會失效泽台。

如何解決呢？

需要對%進(jìn)行轉(zhuǎn)義：/%呀忧。

轉(zhuǎn)義后的sql變成：

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

只會返回包含%的用戶师痕。

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

在java中如果使用mybatis作為持久化框架而账，在mapper.xml文件中胰坟，如果入?yún)⑹褂?code>#傳值，會使用預(yù)編譯機制泞辐。

一般我們是這樣用的：

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

絕大多數(shù)情況下笔横，鼓勵大家使用#這種方式傳參，更安全咐吼，效率更高吹缔。

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

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

sortString字段的內(nèi)容是一個方法中動態(tài)計算出來的锯茄，這種情況是沒法用#厢塘，代替$的，這樣程序會報錯肌幽。

使用$的情況就有sql注入的風(fēng)險晚碾。

那么這種情況該怎辦呢？

1. 自己寫個util工具過濾掉所有的注入關(guān)鍵字喂急，動態(tài)計算時調(diào)用該工具格嘁。
2. 如果數(shù)據(jù)源用的阿里的druid的話，可以開啟filter中的wall（防火墻）廊移，它包含了防止sql注入的功能糕簿。但是有個問題，就是它默認(rèn)不允許多語句同時操作狡孔，對批量更新操作也會攔截懂诗，這就需要我們自定義filter了。

6.表信息是如何泄露的步氏？

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

方法1：盲猜

就是攻擊者根據(jù)常識猜測可能存在的表名稱芋类。

假設(shè)我們有這樣的查詢條件：

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ù)返回隆嗅，說明user表存在，被猜中了侯繁。

建議表名不要起得過于簡單胖喳，可以帶上適當(dāng)?shù)那熬Y，比如：t_user贮竟。 這樣可以增加盲猜的難度丽焊。

方法2：通過系統(tǒng)表

其實mysql有些系統(tǒng)表，可以查到我們自定義的數(shù)據(jù)庫和表的信息咕别。

假設(shè)我們還是以這條sql為例：

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

第一步技健，獲取數(shù)據(jù)庫和賬號名。

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

最終執(zhí)行sql變成：

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

會返回當(dāng)前 數(shù)據(jù)庫名稱：sue 和 賬號名稱：root@localhost惰拱。

image.png

第二步雌贱，獲取表名。

傳參改成：-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'#

會返回數(shù)據(jù)庫sue下面所有表名偿短。

image.png

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

1. 核心數(shù)據(jù)泄露

大部分攻擊者的目的是為了賺錢，說白了就是獲取到有價值的信息拿出去賣錢昔逗，比如：用戶賬號降传、密碼、手機號勾怒、身份證信息婆排、銀行卡號、地址等敏感信息笔链。

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

-1; select * from user;--

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

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

2. 刪庫跑路

也不乏有些攻擊者不按常理出牌缚够，sql注入后直接把系統(tǒng)的表或者數(shù)據(jù)庫都刪了幔妨。

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

-1; delete from user;--

以上語句會刪掉user表中所有數(shù)據(jù)。

-1; drop database test;--

以上語句會把整個test數(shù)據(jù)庫所有內(nèi)容都刪掉谍椅。

正常情況下误堡，我們需要控制線上賬號的權(quán)限，只允許DML（data manipulation language）數(shù)據(jù)操縱語言語句雏吭，包括：select锁施、update、insert、delete等悉抵。

不允許DDL（data definition language）數(shù)據(jù)庫定義語言語句肩狂，包含：create、alter姥饰、drop等傻谁。

也不允許DCL（Data Control Language）數(shù)據(jù)庫控制語言語句，包含：grant,deny,revoke等列粪。

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

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

3. 把系統(tǒng)搞掛

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

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

-1;鎖表語句;--

把表長時間鎖住后吕喘，可能會導(dǎo)致數(shù)據(jù)庫連接耗盡赘那。

這時，我們需要對數(shù)據(jù)庫線程做監(jiān)控氯质，如果某條sql執(zhí)行時間太長募舟，要郵件預(yù)警。此外闻察，合理設(shè)置數(shù)據(jù)庫連接的超時時間拱礁，也能稍微緩解一下這類問題。

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

8. 如何防止sql注入？

1. 使用預(yù)編譯機制

盡量用預(yù)編譯機制陈辱，少用字符串拼接的方式傳參奖年，它是sql注入問題的根源。

2. 要對特殊字符轉(zhuǎn)義

有些特殊字符沛贪，比如：%作為like語句中的參數(shù)時，要對其進(jìn)行轉(zhuǎn)義處理。

3. 要捕獲異常

需要對所有的異常情況進(jìn)行捕獲蝙眶，切記接口直接返回異常信息幽纷，因為有些異常信息中包含了sql信息友浸，包括：庫名收恢，表名伦意，字段名等。攻擊者拿著這些信息离钝，就能通過sql注入隨心所欲的攻擊你的數(shù)據(jù)庫了卵渴。目前比較主流的做法是浪读，有個專門的網(wǎng)關(guān)服務(wù)，它統(tǒng)一暴露對外接口。用戶請求接口時先經(jīng)過它，再由它將請求轉(zhuǎn)發(fā)給業(yè)務(wù)服務(wù)犹撒。這樣做的好處是：能統(tǒng)一封裝返回數(shù)據(jù)的返回體，并且如果出現(xiàn)異常，能返回統(tǒng)一的異常信息刃跛，隱藏敏感信息。此外還能做限流和權(quán)限控制蛙酪。

4. 使用代碼檢測工具

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

5. 要有監(jiān)控

需要對數(shù)據(jù)庫sql的執(zhí)行情況進(jìn)行監(jiān)控，有異常情況菱父，及時郵件或短信提醒蛹磺。

6. 數(shù)據(jù)庫賬號需控制權(quán)限

對生產(chǎn)環(huán)境的數(shù)據(jù)庫建立單獨的賬號萤捆，只分配DML相關(guān)權(quán)限俗批，且不能訪問系統(tǒng)表岁忘。切勿在程序中直接使用管理員賬號干像。

7. 代碼review

建立代碼review機制，能找出部分隱藏的問題什乙，提升代碼質(zhì)量忆某。

8. 使用其他手段處理

對于不能使用預(yù)編譯傳參時状原，要么開啟druid的filter防火墻削锰，要么自己寫代碼邏輯過濾掉所有可能的注入關(guān)鍵字蛹稍。