化查詢(xún)：SRM系統(tǒng)receiptDetail接口安全修復(fù)全記錄)
把 SQL 拼接換掉之后很多同事問(wèn)我同一個(gè)問(wèn)題為什么一個(gè)接口參數(shù)沒(méi)處理好就能讓整個(gè)采購(gòu)系統(tǒng)的收貨數(shù)據(jù)裸奔出來(lái)。其實(shí)問(wèn)題的關(guān)鍵不在于攻擊手法有多高明而在于 SQL 語(yǔ)句的生成方式從一開(kāi)始就走錯(cuò)了路。下面這篇文章是我整理的一份完整記錄包含漏洞成因、本地復(fù)現(xiàn)驗(yàn)證思路、POC 設(shè)計(jì)定位以及最終修復(fù)和回歸檢測(cè)的全過(guò)程希望能給正在排查同類(lèi)問(wèn)題的讀者一點(diǎn)參考。SRM 智聯(lián)云采系統(tǒng)的 receiptDetail 接口負(fù)責(zé)按收貨單維度查詢(xún)明細(xì)數(shù)據(jù)。這個(gè)接口在收貨列表、詳情展示、對(duì)賬導(dǎo)出等多個(gè)場(chǎng)景都會(huì)被調(diào)用屬于典型的高頻數(shù)據(jù)出口。而我正是在評(píng)估該接口時(shí)發(fā)現(xiàn)它存在一個(gè)可被利用的 SQL 注入漏洞。為了方便復(fù)盤(pán)我把整個(gè)分析過(guò)程拆成了漏洞背景、原理拆解、復(fù)現(xiàn)驗(yàn)證、修復(fù)加固和問(wèn)題排查五大部分閱讀時(shí)你可以根據(jù)自己的角色挑選重點(diǎn)開(kāi)發(fā)同學(xué)重點(diǎn)看第 4 部分安全測(cè)試同學(xué)重點(diǎn)看第 2、3 部分運(yùn)維同學(xué)建議把第 4 和第 5 部分一起看完。1. 漏洞背景與影響面分析1.1 receiptDetail 接口在采購(gòu)業(yè)務(wù)中的位置SRM 系統(tǒng)的全稱(chēng)是 Supplier Relationship Management也就是供應(yīng)商關(guān)系管理。它承載著采購(gòu)方和供應(yīng)商之間的主要協(xié)作流程尋源、合同、訂單、發(fā)貨、收貨、對(duì)賬幾乎每個(gè)環(huán)節(jié)都在產(chǎn)生數(shù)據(jù)。而收貨環(huán)節(jié)里最核心的數(shù)據(jù)載體就是收貨單和它的明細(xì)行。receiptDetail 這個(gè)接口做的就是按收貨單 ID 查詢(xún)對(duì)應(yīng)的明細(xì)數(shù)據(jù)返回商品編碼、數(shù)量、含稅單價(jià)、供應(yīng)商批次信息、庫(kù)位等字段。從接口命名就能看出detail 意味著它深入到業(yè)務(wù)的最細(xì)粒度。只要是涉及收貨單的頁(yè)面幾乎都會(huì)調(diào)用這個(gè)接口收貨列表頁(yè)要看明細(xì)摘要、詳情頁(yè)要展示完整字段、導(dǎo)出報(bào)表時(shí)需要做分頁(yè)查詢(xún)、對(duì)賬流程中還要按供應(yīng)商維度匯總數(shù)據(jù)?？梢哉f(shuō)它是整個(gè)收貨流程的數(shù)據(jù)中樞。這個(gè)接口的數(shù)據(jù)價(jià)值非常高。價(jià)格、數(shù)量、供應(yīng)商主體信息、付款參考數(shù)據(jù)都在明細(xì)里攻擊者一旦拿到查詢(xún)能力實(shí)際上就掌握了采購(gòu)業(yè)務(wù)的核心數(shù)據(jù)面。更麻煩的是很多早期建設(shè)的采購(gòu)系統(tǒng)接口沒(méi)有嚴(yán)格區(qū)分內(nèi)網(wǎng)和供應(yīng)商門(mén)戶(hù)的調(diào)用方式。同一個(gè)查詢(xún)邏輯既服務(wù)于內(nèi)部管理端也可能暴露在供應(yīng)商可訪問(wèn)的門(mén)戶(hù)接口中。這意味著風(fēng)險(xiǎn)半徑不只限于企業(yè)內(nèi)部賬號(hào)還可能延伸到整個(gè)供應(yīng)商生態(tài)。1.2 為什么這類(lèi)老采購(gòu)系統(tǒng)總是容易中招我在評(píng)估過(guò)的多個(gè)采購(gòu)類(lèi)系統(tǒng)中發(fā)現(xiàn)SQL 注入在存量業(yè)務(wù)系統(tǒng)里的出現(xiàn)頻率遠(yuǎn)比想象中高。這類(lèi)系統(tǒng)普遍存在幾個(gè)共性第一是歷史代碼包袱重。部分核心查詢(xún)代碼可能是多年前開(kāi)發(fā)的當(dāng)時(shí)團(tuán)隊(duì)的開(kāi)發(fā)規(guī)范還不嚴(yán)格為了快速上線(xiàn)SQL 語(yǔ)句采用字符串拼接的方式執(zhí)行參數(shù)直接混進(jìn) SQL 文本里。后來(lái)系統(tǒng)迭代多次但基礎(chǔ)查詢(xún)邏輯很少有人重構(gòu)隱患就這樣被保留下來(lái)。第二是 ORM 使用不規(guī)范。很多項(xiàng)目用了持久層框架比如 MyBatis但團(tuán)隊(duì)對(duì)${}和#{}的差異理解不透徹。復(fù)習(xí)一下#{}在預(yù)編譯階段會(huì)生成占位符由 PreparedStatement 傳值參數(shù)永遠(yuǎn)不會(huì)改變 SQL 結(jié)構(gòu)而${}是直接把值拼進(jìn) SQL 文本如果值是外部可控的等于把 SQL 的一部分控制權(quán)交給了調(diào)用者。一個(gè)參數(shù)用了${}整個(gè)接口的基本防線(xiàn)就沒(méi)了。第三是內(nèi)網(wǎng)安全假設(shè)失效。早期系統(tǒng)部署在隔離網(wǎng)絡(luò)默認(rèn)只有內(nèi)網(wǎng)人員能訪問(wèn)安全問(wèn)題不明顯。但后來(lái)系統(tǒng)逐漸遷移到云環(huán)境或者通過(guò) API 網(wǎng)關(guān)對(duì)外提供接口暴露面擴(kuò)大了很多倍而原有的查詢(xún)邏輯并沒(méi)有同步收緊。第四是接口數(shù)量多、測(cè)試覆蓋不足。采購(gòu)系統(tǒng)動(dòng)輒幾十個(gè)查詢(xún)接口每個(gè)接口都有若干參數(shù)。很多團(tuán)隊(duì)在上線(xiàn)時(shí)只驗(yàn)證功能是否正常很少針對(duì)非法輸入設(shè)計(jì)測(cè)試用例。數(shù)據(jù)庫(kù)報(bào)錯(cuò)、響應(yīng)異常、響應(yīng)時(shí)間異常這些信號(hào)在真實(shí)環(huán)境里往往被當(dāng)作普通故障忽略了。這些因素疊加起來(lái)使 receiptDetail 這類(lèi)高頻查詢(xún)接口成了高危漏洞的高發(fā)地。理解這些背景再去看后面的漏洞成因就會(huì)清楚很多。2. 漏洞成因與 SQL 注入原理解析2.1 從 HTTP 參數(shù)到 SQL 執(zhí)行一條危險(xiǎn)拼接鏈路receiptDetail 這類(lèi)查詢(xún)接口典型的請(qǐng)求鏈路是HTTP 請(qǐng)求到達(dá)控制器控制器解析 URL 中的參數(shù)傳遞給 Service 層Service 層封裝查詢(xún)條件后由持久層框架執(zhí)行 SQL。問(wèn)題往往發(fā)生在最后一步也就是 SQL 語(yǔ)句生成階段。曾經(jīng)有問(wèn)題的代碼簡(jiǎn)化以后大概是這樣的GetMapping(/api/receipt/detail) public ListMapString, Object queryDetail(RequestParam(id) String id, RequestParam(defaultValue 1) int page, RequestParam(defaultValue 10) int size) { return receiptDetailMapper.queryList(id, page, size); }對(duì)應(yīng)的 MyBatis 映射文件里如果是這樣寫(xiě)的select idqueryList resultTypemap SELECT * FROM receipt_detail WHERE id ${id} ORDER BY create_time DESC LIMIT #{offset}, #{size} /select這段 XML 里id參數(shù)使用了${id}。當(dāng)請(qǐng)求參數(shù)id傳入一個(gè)普通值1001時(shí)SQL 會(huì)正常執(zhí)行。但如果id被傳入巧妙的輸入SQL 語(yǔ)句就變成了完全不同的樣子。原因很簡(jiǎn)單${id}在做字符串替換時(shí)不會(huì)對(duì)參數(shù)做任何類(lèi)型處理和轉(zhuǎn)義外部的所有字符都會(huì)被原樣放進(jìn) SQL 文本。我在評(píng)審代碼時(shí)有一個(gè)很直觀的類(lèi)比方式。#{}就像面試官把問(wèn)題念給候選人聽(tīng)候選人的任何回答都只是內(nèi)容不會(huì)被當(dāng)成新的問(wèn)題繼續(xù)執(zhí)行而${}則是把候選人的回答直接補(bǔ)充進(jìn)面試流程的下一個(gè)環(huán)節(jié)如果回答是精心構(gòu)造的指令整個(gè)流程就會(huì)偏離正常軌道。2.2 閉合、注釋與條件改變注入的底層邏輯SQL 注入能成立核心在于字符串拼接破壞了 SQL 原本的語(yǔ)法結(jié)構(gòu)。為了方便理解我用一個(gè)簡(jiǎn)化說(shuō)明當(dāng)代碼里這樣寫(xiě)時(shí)WHERE id ${id}如果用戶(hù)傳入1001 AND 11拼出來(lái)的 SQL 會(huì)變成WHERE id 1001 AND 11這個(gè) SQL 依然能正常執(zhí)行但語(yǔ)義已經(jīng)被改變。第一個(gè)條件是id 1001恒真的附加條件是11。由于第二個(gè)條件永遠(yuǎn)為真查詢(xún)結(jié)果實(shí)際上不再?lài)?yán)格受 id 限制。如果把恒真條件替換成恒假條件例如1001 AND 12拼出來(lái)的 SQL 會(huì)變成WHERE id 1001 AND 12由于12永遠(yuǎn)為假查詢(xún)結(jié)果會(huì)是空集。相比正常請(qǐng)求響應(yīng)結(jié)果出現(xiàn)明顯差異。這種差異就是安全測(cè)試中常說(shuō)的“布爾條件判斷”。它說(shuō)明參數(shù)不僅進(jìn)入了 SQL還直接參與了查詢(xún)條件的邏輯運(yùn)算。除了改變條件還可以通過(guò)注釋符把后面的 SQL 內(nèi)容截?cái)嗟?。在?shù)據(jù)庫(kù)語(yǔ)法里注釋符可以把后續(xù)文本變成注釋從而繞過(guò)原本附加在 SQL 末尾的查詢(xún)條件。這個(gè)技巧有時(shí)會(huì)讓原本限制數(shù)據(jù)范圍的 SQL 條件失效加深危害。不過(guò)這里并不展開(kāi)具體繞過(guò)手法核心是想說(shuō)明一個(gè)原理只要輸入能改變 SQL 結(jié)構(gòu)查詢(xún)邊界就不再受開(kāi)發(fā)者控制。2.3 這類(lèi)漏洞為什么危險(xiǎn)很多非安全背景的讀者會(huì)想就算能改變查詢(xún)條件也查不到更多數(shù)據(jù)吧實(shí)際情況并非如此。這類(lèi)查詢(xún)接口背后的表往往不只是收貨明細(xì)本身還可能通過(guò)關(guān)聯(lián)查詢(xún)帶出供應(yīng)商主體信息、采購(gòu)訂單信息、結(jié)算數(shù)據(jù)等。SQL 注入一旦成立攻擊者可以逐步擴(kuò)大查詢(xún)范圍甚至結(jié)合數(shù)據(jù)庫(kù)自身的報(bào)文特性獲取更多內(nèi)容。真正讓它危險(xiǎn)的原因有三點(diǎn)一是數(shù)據(jù)敏感。收貨明細(xì)里包含價(jià)格、數(shù)量、供應(yīng)商賬戶(hù)信息這些數(shù)據(jù)一旦泄露可能被用于商業(yè)情報(bào)收集甚至進(jìn)一步詐騙。二是接口可達(dá)性高。receiptDetail 是高頻接口且可能出現(xiàn)在供應(yīng)商門(mén)戶(hù)、開(kāi)放 API、移動(dòng)端接口等多個(gè)入口。攻擊者不一定需要攻破后臺(tái)系統(tǒng)只要找到了一個(gè)帶有參數(shù)的查詢(xún)?nèi)肟诰涂梢試L試探測(cè)。三是數(shù)據(jù)庫(kù)權(quán)限往往過(guò)大。很多老系統(tǒng)的數(shù)據(jù)庫(kù)賬號(hào)是應(yīng)用賬號(hào)直連權(quán)限大多很大甚至具備寫(xiě)文件、調(diào)用系統(tǒng)命令等高危權(quán)限。SQL 注入一旦配合這類(lèi)權(quán)限就不再只是數(shù)據(jù)查詢(xún)問(wèn)題可能演變?yōu)榉?wù)器層面的嚴(yán)重風(fēng)險(xiǎn)。3. 本地靶場(chǎng)復(fù)現(xiàn)與 POC 驗(yàn)證思路3.1 搭一個(gè)能放心驗(yàn)證的隔離環(huán)境復(fù)現(xiàn)這類(lèi)漏洞前提是獲得合法授權(quán)并且在隔離的本地環(huán)境中進(jìn)行。我不建議任何人拿線(xiàn)上系統(tǒng)直接試驗(yàn)這一點(diǎn)必須放在最前面說(shuō)。我當(dāng)時(shí)的做法是在一臺(tái)本地虛擬機(jī)里用 Docker 搭建了一套最小復(fù)現(xiàn)環(huán)境只保留和漏洞相關(guān)的基礎(chǔ)組件。環(huán)境清單大致如下組件選型說(shuō)明應(yīng)用框架Spring Boot 2.x MyBatis模擬真實(shí)查詢(xún)接口的請(qǐng)求鏈路數(shù)據(jù)庫(kù)MySQL 8.0用來(lái)觀察 SQL 執(zhí)行行為和報(bào)錯(cuò)信息樣例數(shù)據(jù)100 條左右模擬收貨單明細(xì)保證查詢(xún)有正常、空集、報(bào)錯(cuò)三種響應(yīng)場(chǎng)景測(cè)試工具瀏覽器 DevTools Python 腳本手工驗(yàn)證探針行為和后續(xù)自動(dòng)化回歸數(shù)據(jù)庫(kù)里準(zhǔn)備了模擬數(shù)據(jù)每張明細(xì)都包含收貨單 ID、物料編碼、數(shù)量、單價(jià)、供應(yīng)商編碼等字段。這里需要注意靶場(chǎng)數(shù)據(jù)不要直接用真實(shí)脫敏數(shù)據(jù)最好完全隨機(jī)生成避免合規(guī)風(fēng)險(xiǎn)。環(huán)境啟動(dòng)后第一步是發(fā)起正常查詢(xún)請(qǐng)求確認(rèn)接口的基礎(chǔ)功能和響應(yīng)結(jié)構(gòu)。比如請(qǐng)求GET /api/receipt/detail?id1001page1size10正常響應(yīng)會(huì)返回一條或多條明細(xì)記錄。記錄下響應(yīng)體的長(zhǎng)度和業(yè)務(wù)字段后續(xù)所有驗(yàn)證都會(huì)拿這一步的結(jié)果做參照。3.2 注入點(diǎn)定位從一口“報(bào)錯(cuò)”說(shuō)起我定位注入點(diǎn)的過(guò)程可以分為四步每一步都非常簡(jiǎn)單但每一步都有明確的判斷目標(biāo)。第一步請(qǐng)求正常參數(shù)。正常獲取 id1001 的響應(yīng)確認(rèn)接口行為是穩(wěn)定查詢(xún)。第二步在參數(shù)末尾追加一個(gè)單引號(hào)。如果原來(lái)的查詢(xún)條件寫(xiě)法是WHERE id ${id}那么單引號(hào)會(huì)讓 SQL 的字符串閉合出現(xiàn)錯(cuò)亂數(shù)據(jù)庫(kù)往往直接報(bào)語(yǔ)法錯(cuò)誤。響應(yīng)中可能會(huì)出現(xiàn) 500 狀態(tài)碼錯(cuò)誤頁(yè)面里可能直接暴露原始 SQL 或數(shù)據(jù)庫(kù)異常信息。這一步的意義是確認(rèn)參數(shù)是否被原樣拼入了 SQL。第三步字符型布爾驗(yàn)證。把 id 換成1001 AND 11如果返回值與正常請(qǐng)求一致說(shuō)明 SQL 中的條件被成功吸收額外條件恒真且沒(méi)有破壞整體語(yǔ)句。第四步恒假條件驗(yàn)證。把 id 換成1001 AND 12如果返回值變成空集或返回記錄數(shù)明顯變化說(shuō)明參數(shù)已經(jīng)參與邏輯判斷。到這一步基本可以判斷該參數(shù)存在可被利用的 SQL 注入風(fēng)險(xiǎn)。需要說(shuō)明的是這里展示的探針只是用于確認(rèn)風(fēng)險(xiǎn)是否存在并不涉及任何數(shù)據(jù)獲取行為。全部驗(yàn)證都在本地靶場(chǎng)完成生產(chǎn)系統(tǒng)和未授權(quán)目標(biāo)一律不允許做類(lèi)似操作。3.3 設(shè)計(jì)一個(gè)輕量的 POC 腳本確認(rèn)注入點(diǎn)存在后我寫(xiě)了一個(gè)最小化的驗(yàn)證腳本用途不是攻擊而是固化驗(yàn)證邏輯方便后續(xù)回歸時(shí)反復(fù)使用。腳本的思路非常簡(jiǎn)單對(duì)同一參數(shù)同時(shí)發(fā)起正常請(qǐng)求、恒真條件請(qǐng)求、恒假條件請(qǐng)求對(duì)比三組響應(yīng)的長(zhǎng)度和狀態(tài)碼就能自動(dòng)判斷是否存在字符型注入風(fēng)險(xiǎn)。以下腳本只適合在本地授權(quán)靶場(chǎng)中使用 本地靶場(chǎng) SQL 注入布爾探針腳本 僅用于授權(quán)環(huán)境下的漏洞確認(rèn)和安全回歸測(cè)試嚴(yán)禁對(duì)未授權(quán)系統(tǒng)使用 import requests BASE_URL http://127.0.0.1:8080/api/receipt/detail TARGET_ID 1001 def build_params(pid): normal {id: pid, page: 1, size: 10} # 恒真條件用于確認(rèn)請(qǐng)求是否能被正常吸收 true_cond {id: f{pid} AND 11, page: 1, size: 10} # 恒假條件用于確認(rèn)是否參與查詢(xún)邏輯 false_cond {id: f{pid} AND 12, page: 1, size: 10} return normal, true_cond, false_cond def probe(pid): normal, true_cond, false_cond build_params(pid) results [] for params in (normal, true_cond, false_cond): try: resp requests.get(BASE_URL, paramsparams, timeout5) results.append((resp.status_code, len(resp.text))) except Exception as exc: results.append((0, str(exc))) return results if __name__ __main__: ret probe(TARGET_ID) normal_len ret[0][1] true_len ret[1][1] false_len ret[2][1] print(fnormal: {ret[0]}) print(ftrue: {ret[1]}) print(ffalse: {ret[2]}) # 若恒真與正常響應(yīng)存在一致特征而恒假響應(yīng)明顯變短或變空則說(shuō)明條件已生效 if false_len normal_len: print(疑似存在字符型 SQL 注入風(fēng)險(xiǎn)請(qǐng)結(jié)合人工判斷) else: print(未發(fā)現(xiàn)明顯差異請(qǐng)檢查是否存在其它拼接點(diǎn))腳本本身很短但設(shè)計(jì)上考慮了三點(diǎn)一是所有請(qǐng)求都帶超時(shí)防止資源占用二是只比較響應(yīng)長(zhǎng)度不做數(shù)據(jù)獲取三是輸出結(jié)果不依賴(lài)具體業(yè)務(wù)字段可以快速接入后續(xù)的自動(dòng)化回歸流程。在實(shí)際復(fù)現(xiàn)過(guò)程中我還建議把三組請(qǐng)求的完整響應(yīng)保存下來(lái)尤其是真實(shí)請(qǐng)求和恒假請(qǐng)求的差異。如果恒假請(qǐng)求返回空列表或者條目明顯減少說(shuō)明條件已經(jīng)生效直接定位問(wèn)題的證據(jù)就有了。4. 修復(fù)方案與縱深防御實(shí)踐4.1 根因修復(fù)從 ${} 到 #{} 不只是改一個(gè)符號(hào)修復(fù) SQL 注入最徹底的方法永遠(yuǎn)是消除 SQL 字符串拼接使用參數(shù)化查詢(xún)。對(duì) MyBatis 來(lái)說(shuō)就是把${}替換成#{}。把前面那段有問(wèn)題的 XML 改掉后應(yīng)當(dāng)是select idqueryList resultTypemap SELECT * FROM receipt_detail WHERE id #{id} ORDER BY create_time DESC LIMIT #{offset}, #{size} /select注意這里有兩個(gè)細(xì)節(jié)第一#{}生成的是預(yù)編譯占位符參數(shù)會(huì)在執(zhí)行階段由驅(qū)動(dòng)安全傳值不會(huì)改變 SQL 結(jié)構(gòu)。JDBC 層面會(huì)自動(dòng)處理轉(zhuǎn)義單引號(hào)、反斜杠等特殊字符都只是字符串內(nèi)容不會(huì)再被當(dāng)作 SQL 語(yǔ)法元素。第二改造過(guò)程中容易踩坑的是動(dòng)態(tài)條件。比如常見(jiàn)查詢(xún)里按訂單號(hào)、供應(yīng)商編碼、狀態(tài)等字段做動(dòng)態(tài)拼接如果改造不完整改造后的接口依然會(huì)有遺漏的拼接點(diǎn)。最穩(wěn)妥的做法是把查詢(xún)語(yǔ)句里所有參數(shù)都過(guò)一遍凡是可能被外部輸入的一律使用#{}占位。另外LIKE 模糊查詢(xún)的場(chǎng)景要注意寫(xiě)法。比如查詢(xún)收貨備注信息select idqueryByKeyword resultTypemap SELECT * FROM receipt_detail WHERE remark LIKE CONCAT(%, #{keyword}, %) /select不要把參數(shù)直接拼進(jìn)%${keyword}%。使用CONCAT函數(shù)把模糊查詢(xún)的特殊字符和參數(shù)分開(kāi)傳參既安全又保持查詢(xún)語(yǔ)義。動(dòng)態(tài)排序字段是另一個(gè)常見(jiàn)遺漏點(diǎn)。比如ORDER BY ${sortField}排序字段名無(wú)法使用占位符需要通過(guò)白名單方式解決。正確做法是String sortField create_time; // 默認(rèn)值 if (update_time.equals(param.getSortField())) { sortField update_time; } else if (quantity.equals(param.getSortField())) { sortField quantity; }只有白名單里明確的字段名才允許進(jìn)入 SQL 文本。外部傳入的任何其他字段名一律使用默認(rèn)值。4.2 接口層、數(shù)據(jù)層、配置層的組合拳根因修復(fù)雖然解決了注入本身但為了確保系統(tǒng)整體安全還需要做幾層加固。這里有一個(gè)觀念上的變化安全不是只修一個(gè)漏洞而是要讓同類(lèi)問(wèn)題在后續(xù)迭代中盡量少出現(xiàn)。接口層要做的事有三件一是參數(shù)校驗(yàn)。請(qǐng)求參數(shù)進(jìn)入控制器后第一時(shí)間做類(lèi)型和取值校驗(yàn)。id 應(yīng)當(dāng)是數(shù)字類(lèi)型receiptType 應(yīng)當(dāng)在系統(tǒng)預(yù)定義的枚舉范圍內(nèi)。不符合格式的直接返回 400不再進(jìn)入業(yè)務(wù)邏輯。二是數(shù)據(jù)權(quán)限校驗(yàn)。收貨明細(xì)查詢(xún)不能只依賴(lài) SQL 條件。Service 層需要根據(jù)當(dāng)前登錄用戶(hù)所屬供應(yīng)商或采購(gòu)組織把可查詢(xún)的范圍限制住。這部分邏輯放在業(yè)務(wù)代碼里比 SQL 條件更可控。三是返回字段最小化。接口只返回前端必要的字段不要把整行數(shù)據(jù)的所有字段都附帶返回。減少數(shù)據(jù)暴露面可以降低單次接口被異常調(diào)用時(shí)的損失。數(shù)據(jù)層的加固重點(diǎn)在數(shù)據(jù)庫(kù)賬號(hào)權(quán)限。業(yè)務(wù)應(yīng)用對(duì)應(yīng)的數(shù)據(jù)庫(kù)賬號(hào)原則上只保留查詢(xún)和必要寫(xiě)入權(quán)限。報(bào)表查詢(xún)類(lèi)賬號(hào)可以單獨(dú)建立只讀賬號(hào)避免應(yīng)用被注入時(shí)擁有過(guò)高權(quán)限。數(shù)據(jù)庫(kù)賬號(hào)也不要啟用文件讀寫(xiě)、命令執(zhí)行等高級(jí)權(quán)限這類(lèi)權(quán)限在實(shí)際業(yè)務(wù)中大多用不到。配置層的加固主要是網(wǎng)關(guān)和 WAF。在系統(tǒng)入口處加上基礎(chǔ)注入特征攔截規(guī)則比如包含明顯恒真條件、數(shù)據(jù)庫(kù)注釋符、報(bào)錯(cuò)函數(shù)特征的請(qǐng)求直接拒絕。但這里必須說(shuō)一句WAF 是兜底手段不是根本解決方案。它能攔截掉一部分已知特征卻很難完全擋住精心構(gòu)造的繞行語(yǔ)法。真正能兜住底的是代碼里不再出現(xiàn)拼接點(diǎn)。4.3 修復(fù)后的驗(yàn)證與回歸修復(fù)完成后需要重新走一遍驗(yàn)證流程。我習(xí)慣用一張簡(jiǎn)單的對(duì)照表來(lái)梳理測(cè)試場(chǎng)景構(gòu)造輸入預(yù)期結(jié)果正常路徑id1001page1size10正常返回明細(xì)數(shù)據(jù)恒真條件id1001 AND 11返回正常數(shù)據(jù)與恒真條件無(wú)關(guān)恒假條件id1001 AND 12不因?yàn)楹慵贄l件而返回空集非法類(lèi)型參數(shù)idabc返回參數(shù)校驗(yàn)錯(cuò)誤排序字段異常sortFieldid; DROP TABLE不生效回退默認(rèn)排序驗(yàn)證時(shí)不要只看 HTTP 狀態(tài)碼和前端表現(xiàn)一定要打開(kāi)數(shù)據(jù)庫(kù)日志。觀察數(shù)據(jù)庫(kù)實(shí)際收到的 SQL 語(yǔ)句。如果日志中出現(xiàn)id 1001這樣帶引號(hào)的值說(shuō)明參數(shù)是通過(guò)占位符傳入的如果出現(xiàn)拼接后的完整 SQL說(shuō)明鏈路上還有殘留拼接點(diǎn)需要繼續(xù)排查。回歸驗(yàn)證還要覆蓋原有業(yè)務(wù)場(chǎng)景。改動(dòng) SQL 后正常查詢(xún)、分頁(yè)、排序、導(dǎo)出等原有功能需要重新執(zhí)行一遍防止因?yàn)閰?shù)化改造破壞業(yè)務(wù)邏輯。尤其是分頁(yè)接口如果查詢(xún)條件發(fā)生變化分頁(yè)總數(shù)的返回可能會(huì)不符合預(yù)期需要仔細(xì)核對(duì)。把上面提到的驗(yàn)證用例固化下來(lái)放到接口測(cè)試用例集里。以后每次發(fā)布新版本只要運(yùn)行一遍就能在最短時(shí)間內(nèi)發(fā)現(xiàn) SQL 拼接是否回歸。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 復(fù)現(xiàn)時(shí)響應(yīng)不符合預(yù)期問(wèn)題出在哪復(fù)現(xiàn)過(guò)程看起來(lái)簡(jiǎn)單實(shí)際操作中很容易碰壁。最典型的幾個(gè)問(wèn)題第一參數(shù)編碼問(wèn)題。直接通過(guò)瀏覽器地址欄輸入 AND 11時(shí)部分字符可能被瀏覽器自動(dòng)編碼或者被中間件截?cái)唷Ｓ绕涫?符號(hào)URL 定位符與其后面的文本通常不會(huì)被發(fā)送到服務(wù)器因此注釋類(lèi)字符必須做 URL 編碼否則測(cè)試結(jié)果就不真實(shí)。第二請(qǐng)求方法不一致。有的查詢(xún)接口只接收 POST 請(qǐng)求參數(shù)放在請(qǐng)求體里用 GET 方式的探針自然毫無(wú)反應(yīng)。正確的做法是先抓取真實(shí)前端請(qǐng)求確認(rèn)請(qǐng)求方法和請(qǐng)求體格式再在同樣格式下構(gòu)造探針。第三數(shù)據(jù)庫(kù)錯(cuò)誤信息被屏蔽。有些系統(tǒng)的全局異常處理器把數(shù)據(jù)庫(kù)報(bào)錯(cuò)統(tǒng)一轉(zhuǎn)換成通用提示即使探針觸發(fā)了語(yǔ)法錯(cuò)誤響應(yīng)里也看不到任何 SQL 痕跡。這時(shí)不能只依賴(lài)報(bào)錯(cuò)信號(hào)還要結(jié)合布爾條件響應(yīng)差異來(lái)判斷。我的排查思路很簡(jiǎn)單先把真實(shí)請(qǐng)求完整抓包確認(rèn)參數(shù)位置和編碼格式再在靶場(chǎng)環(huán)境里調(diào)整探針格式一項(xiàng)項(xiàng)排查直到能穩(wěn)定復(fù)現(xiàn)。5.2 修完仍然被掃描器報(bào)漏洞怎么排查這是很多團(tuán)隊(duì)修復(fù)后最頭疼的問(wèn)題。代碼已經(jīng)改成了#{}但安全掃描報(bào)告依然告警。我遇到過(guò)的原因主要有三類(lèi)。第一類(lèi)接口內(nèi)部存在多個(gè)拼接點(diǎn)只改了一處。一個(gè)接口可能同時(shí)支持多個(gè)查詢(xún)參數(shù)改造時(shí)只處理了注入明顯的字段其他字段仍是${}。掃描器發(fā)往不同參數(shù)立即又能測(cè)出問(wèn)題。排查方法是把接口所有參數(shù)都過(guò)一遍逐一確認(rèn)。第二類(lèi)動(dòng)態(tài) SQL 的視圖或存儲(chǔ)過(guò)程存在拼接。如果查詢(xún)走的是數(shù)據(jù)庫(kù)視圖、存儲(chǔ)過(guò)程而視圖或存儲(chǔ)過(guò)程內(nèi)部使用了動(dòng)態(tài)執(zhí)行語(yǔ)句即使應(yīng)用層已改掉底層仍可能在執(zhí)行過(guò)程中拼接。這種情況需要把數(shù)據(jù)庫(kù)端對(duì)象和日志結(jié)合起來(lái)排查。第三類(lèi)其他代碼路徑調(diào)用同一個(gè) Mapper。Mapper 方法可能被多個(gè)控制器使用修復(fù)時(shí)只關(guān)注了其中一個(gè)入口但另一個(gè)入口依然傳入未經(jīng)過(guò)濾的字符串。建議全局搜索該 Mapper 方法的所有調(diào)用位置逐一確認(rèn)。排查技巧還是回到日志。修復(fù)后重新復(fù)現(xiàn)一次把數(shù)據(jù)庫(kù)端實(shí)際執(zhí)行的 SQL 全部打印出來(lái)逐條核對(duì)。既然掃描器能測(cè)出來(lái)就說(shuō)明某處一定存在拼接通過(guò)日志可以快速鎖定。5.3 這類(lèi)漏洞的優(yōu)先級(jí)判斷修復(fù)資源有限時(shí)不能所有接口平均用力。判斷優(yōu)先級(jí)可以從三個(gè)維度出發(fā)。一是數(shù)據(jù)敏感度。receiptDetail 這類(lèi)接口返回價(jià)格、數(shù)量、供應(yīng)商信息敏感度很高應(yīng)當(dāng)優(yōu)先修復(fù)。如果接口還關(guān)聯(lián)出賬務(wù)、合同等更高敏感字段優(yōu)先級(jí)再往上提。二是暴露面大小。接口是否被供應(yīng)商門(mén)戶(hù)、移動(dòng)端、開(kāi)放 API 等多個(gè)入口調(diào)用是否不需要復(fù)雜權(quán)限就能訪問(wèn)。暴露面越大修復(fù)優(yōu)先級(jí)越高。三是利用難度。攻擊者利用該接口獲取數(shù)據(jù)是否需要滿(mǎn)足額外條件比如是否依賴(lài)特定賬號(hào)、是否需要繞過(guò)網(wǎng)關(guān)白名單。如果利用條件很低說(shuō)明風(fēng)險(xiǎn)更容易被觸發(fā)應(yīng)當(dāng)放在更前面處理。結(jié)合這三個(gè)維度采購(gòu)系統(tǒng)中的高頻查詢(xún)接口通常處于優(yōu)先修復(fù)的位置。修復(fù)完成之后也別松勁把驗(yàn)證用例和回歸流程沉淀下來(lái)讓這類(lèi)問(wèn)題在團(tuán)隊(duì)中形成固定檢查項(xiàng)。最后分享一個(gè)我自己的習(xí)慣。修復(fù)完注入類(lèi)漏洞之后我不會(huì)刪掉驗(yàn)證用的探針腳本而是會(huì)把它改造為最小化的回歸測(cè)試用例放進(jìn)日常安全測(cè)試中。每次業(yè)務(wù)迭代跑一遍只要有人不小心把參數(shù)重新拼進(jìn) SQL它會(huì)立刻發(fā)出信號(hào)。SQL 注入不一定是技術(shù)難度最高的漏洞但它對(duì)業(yè)務(wù)數(shù)據(jù)的威脅非常直接尤其是采購(gòu)系統(tǒng)這種貼著價(jià)格、合同、供應(yīng)商資金信息走的業(yè)務(wù)一次注入引發(fā)的風(fēng)險(xiǎn)往往不會(huì)只停留在單個(gè)接口而是可能波及多個(gè)關(guān)聯(lián)系統(tǒng)。在開(kāi)發(fā)階段多用十分鐘做預(yù)編譯比上線(xiàn)后再去追生產(chǎn)事故要?jiǎng)澦愕枚唷? 從SQL注入到參數(shù)化查詢(xún)：SRM系統(tǒng)receiptDetail接口安全修復(fù)全記錄
把 SQL 拼接換掉之后很多同事問(wèn)我同一個(gè)問(wèn)題為什么一個(gè)接口參數(shù)沒(méi)處理好就能讓整個(gè)采購(gòu)系統(tǒng)的收貨數(shù)據(jù)裸奔出來(lái)。其實(shí)問(wèn)題的關(guān)鍵不在于攻擊手法有多高明而在于 SQL 語(yǔ)句的生成方式從一開(kāi)始就走錯(cuò)了路。下面這篇文章是我整理的一份完整記錄包含漏洞成因、本地復(fù)現(xiàn)驗(yàn)證思路、POC 設(shè)計(jì)定位以及最終修復(fù)和回歸檢測(cè)的全過(guò)程希望能給正在排查同類(lèi)問(wèn)題的讀者一點(diǎn)參考。SRM 智聯(lián)云采系統(tǒng)的 receiptDetail 接口負(fù)責(zé)按收貨單維度查詢(xún)明細(xì)數(shù)據(jù)。這個(gè)接口在收貨列表、詳情展示、對(duì)賬導(dǎo)出等多個(gè)場(chǎng)景都會(huì)被調(diào)用屬于典型的高頻數(shù)據(jù)出口。而我正是在評(píng)估該接口時(shí)發(fā)現(xiàn)它存在一個(gè)可被利用的 SQL 注入漏洞。為了方便復(fù)盤(pán)我把整個(gè)分析過(guò)程拆成了漏洞背景、原理拆解、復(fù)現(xiàn)驗(yàn)證、修復(fù)加固和問(wèn)題排查五大部分閱讀時(shí)你可以根據(jù)自己的角色挑選重點(diǎn)開(kāi)發(fā)同學(xué)重點(diǎn)看第 4 部分安全測(cè)試同學(xué)重點(diǎn)看第 2、3 部分運(yùn)維同學(xué)建議把第 4 和第 5 部分一起看完。1. 漏洞背景與影響面分析1.1 receiptDetail 接口在采購(gòu)業(yè)務(wù)中的位置SRM 系統(tǒng)的全稱(chēng)是 Supplier Relationship Management也就是供應(yīng)商關(guān)系管理。它承載著采購(gòu)方和供應(yīng)商之間的主要協(xié)作流程尋源、合同、訂單、發(fā)貨、收貨、對(duì)賬幾乎每個(gè)環(huán)節(jié)都在產(chǎn)生數(shù)據(jù)。而收貨環(huán)節(jié)里最核心的數(shù)據(jù)載體就是收貨單和它的明細(xì)行。receiptDetail 這個(gè)接口做的就是按收貨單 ID 查詢(xún)對(duì)應(yīng)的明細(xì)數(shù)據(jù)返回商品編碼、數(shù)量、含稅單價(jià)、供應(yīng)商批次信息、庫(kù)位等字段。從接口命名就能看出detail 意味著它深入到業(yè)務(wù)的最細(xì)粒度。只要是涉及收貨單的頁(yè)面幾乎都會(huì)調(diào)用這個(gè)接口收貨列表頁(yè)要看明細(xì)摘要、詳情頁(yè)要展示完整字段、導(dǎo)出報(bào)表時(shí)需要做分頁(yè)查詢(xún)、對(duì)賬流程中還要按供應(yīng)商維度匯總數(shù)據(jù)?？梢哉f(shuō)它是整個(gè)收貨流程的數(shù)據(jù)中樞。這個(gè)接口的數(shù)據(jù)價(jià)值非常高。價(jià)格、數(shù)量、供應(yīng)商主體信息、付款參考數(shù)據(jù)都在明細(xì)里攻擊者一旦拿到查詢(xún)能力實(shí)際上就掌握了采購(gòu)業(yè)務(wù)的核心數(shù)據(jù)面。更麻煩的是很多早期建設(shè)的采購(gòu)系統(tǒng)接口沒(méi)有嚴(yán)格區(qū)分內(nèi)網(wǎng)和供應(yīng)商門(mén)戶(hù)的調(diào)用方式。同一個(gè)查詢(xún)邏輯既服務(wù)于內(nèi)部管理端也可能暴露在供應(yīng)商可訪問(wèn)的門(mén)戶(hù)接口中。這意味著風(fēng)險(xiǎn)半徑不只限于企業(yè)內(nèi)部賬號(hào)還可能延伸到整個(gè)供應(yīng)商生態(tài)。1.2 為什么這類(lèi)老采購(gòu)系統(tǒng)總是容易中招我在評(píng)估過(guò)的多個(gè)采購(gòu)類(lèi)系統(tǒng)中發(fā)現(xiàn)SQL 注入在存量業(yè)務(wù)系統(tǒng)里的出現(xiàn)頻率遠(yuǎn)比想象中高。這類(lèi)系統(tǒng)普遍存在幾個(gè)共性第一是歷史代碼包袱重。部分核心查詢(xún)代碼可能是多年前開(kāi)發(fā)的當(dāng)時(shí)團(tuán)隊(duì)的開(kāi)發(fā)規(guī)范還不嚴(yán)格為了快速上線(xiàn)SQL 語(yǔ)句采用字符串拼接的方式執(zhí)行參數(shù)直接混進(jìn) SQL 文本里。后來(lái)系統(tǒng)迭代多次但基礎(chǔ)查詢(xún)邏輯很少有人重構(gòu)隱患就這樣被保留下來(lái)。第二是 ORM 使用不規(guī)范。很多項(xiàng)目用了持久層框架比如 MyBatis但團(tuán)隊(duì)對(duì)${}和#{}的差異理解不透徹。復(fù)習(xí)一下#{}在預(yù)編譯階段會(huì)生成占位符由 PreparedStatement 傳值參數(shù)永遠(yuǎn)不會(huì)改變 SQL 結(jié)構(gòu)而${}是直接把值拼進(jìn) SQL 文本如果值是外部可控的等于把 SQL 的一部分控制權(quán)交給了調(diào)用者。一個(gè)參數(shù)用了${}整個(gè)接口的基本防線(xiàn)就沒(méi)了。第三是內(nèi)網(wǎng)安全假設(shè)失效。早期系統(tǒng)部署在隔離網(wǎng)絡(luò)默認(rèn)只有內(nèi)網(wǎng)人員能訪問(wèn)安全問(wèn)題不明顯。但后來(lái)系統(tǒng)逐漸遷移到云環(huán)境或者通過(guò) API 網(wǎng)關(guān)對(duì)外提供接口暴露面擴(kuò)大了很多倍而原有的查詢(xún)邏輯并沒(méi)有同步收緊。第四是接口數(shù)量多、測(cè)試覆蓋不足。采購(gòu)系統(tǒng)動(dòng)輒幾十個(gè)查詢(xún)接口每個(gè)接口都有若干參數(shù)。很多團(tuán)隊(duì)在上線(xiàn)時(shí)只驗(yàn)證功能是否正常很少針對(duì)非法輸入設(shè)計(jì)測(cè)試用例。數(shù)據(jù)庫(kù)報(bào)錯(cuò)、響應(yīng)異常、響應(yīng)時(shí)間異常這些信號(hào)在真實(shí)環(huán)境里往往被當(dāng)作普通故障忽略了。這些因素疊加起來(lái)使 receiptDetail 這類(lèi)高頻查詢(xún)接口成了高危漏洞的高發(fā)地。理解這些背景再去看后面的漏洞成因就會(huì)清楚很多。2. 漏洞成因與 SQL 注入原理解析2.1 從 HTTP 參數(shù)到 SQL 執(zhí)行一條危險(xiǎn)拼接鏈路receiptDetail 這類(lèi)查詢(xún)接口典型的請(qǐng)求鏈路是HTTP 請(qǐng)求到達(dá)控制器控制器解析 URL 中的參數(shù)傳遞給 Service 層Service 層封裝查詢(xún)條件后由持久層框架執(zhí)行 SQL。問(wèn)題往往發(fā)生在最后一步也就是 SQL 語(yǔ)句生成階段。曾經(jīng)有問(wèn)題的代碼簡(jiǎn)化以后大概是這樣的GetMapping(/api/receipt/detail) public ListMapString, Object queryDetail(RequestParam(id) String id, RequestParam(defaultValue 1) int page, RequestParam(defaultValue 10) int size) { return receiptDetailMapper.queryList(id, page, size); }對(duì)應(yīng)的 MyBatis 映射文件里如果是這樣寫(xiě)的select idqueryList resultTypemap SELECT * FROM receipt_detail WHERE id ${id} ORDER BY create_time DESC LIMIT #{offset}, #{size} /select這段 XML 里id參數(shù)使用了${id}。當(dāng)請(qǐng)求參數(shù)id傳入一個(gè)普通值1001時(shí)SQL 會(huì)正常執(zhí)行。但如果id被傳入巧妙的輸入SQL 語(yǔ)句就變成了完全不同的樣子。原因很簡(jiǎn)單${id}在做字符串替換時(shí)不會(huì)對(duì)參數(shù)做任何類(lèi)型處理和轉(zhuǎn)義外部的所有字符都會(huì)被原樣放進(jìn) SQL 文本。我在評(píng)審代碼時(shí)有一個(gè)很直觀的類(lèi)比方式。#{}就像面試官把問(wèn)題念給候選人聽(tīng)候選人的任何回答都只是內(nèi)容不會(huì)被當(dāng)成新的問(wèn)題繼續(xù)執(zhí)行而${}則是把候選人的回答直接補(bǔ)充進(jìn)面試流程的下一個(gè)環(huán)節(jié)如果回答是精心構(gòu)造的指令整個(gè)流程就會(huì)偏離正常軌道。2.2 閉合、注釋與條件改變注入的底層邏輯SQL 注入能成立核心在于字符串拼接破壞了 SQL 原本的語(yǔ)法結(jié)構(gòu)。為了方便理解我用一個(gè)簡(jiǎn)化說(shuō)明當(dāng)代碼里這樣寫(xiě)時(shí)WHERE id ${id}如果用戶(hù)傳入1001 AND 11拼出來(lái)的 SQL 會(huì)變成WHERE id 1001 AND 11這個(gè) SQL 依然能正常執(zhí)行但語(yǔ)義已經(jīng)被改變。第一個(gè)條件是id 1001恒真的附加條件是11。由于第二個(gè)條件永遠(yuǎn)為真查詢(xún)結(jié)果實(shí)際上不再?lài)?yán)格受 id 限制。如果把恒真條件替換成恒假條件例如1001 AND 12拼出來(lái)的 SQL 會(huì)變成WHERE id 1001 AND 12由于12永遠(yuǎn)為假查詢(xún)結(jié)果會(huì)是空集。相比正常請(qǐng)求響應(yīng)結(jié)果出現(xiàn)明顯差異。這種差異就是安全測(cè)試中常說(shuō)的“布爾條件判斷”。它說(shuō)明參數(shù)不僅進(jìn)入了 SQL還直接參與了查詢(xún)條件的邏輯運(yùn)算。除了改變條件還可以通過(guò)注釋符把后面的 SQL 內(nèi)容截?cái)嗟?。在?shù)據(jù)庫(kù)語(yǔ)法里注釋符可以把后續(xù)文本變成注釋從而繞過(guò)原本附加在 SQL 末尾的查詢(xún)條件。這個(gè)技巧有時(shí)會(huì)讓原本限制數(shù)據(jù)范圍的 SQL 條件失效加深危害。不過(guò)這里并不展開(kāi)具體繞過(guò)手法核心是想說(shuō)明一個(gè)原理只要輸入能改變 SQL 結(jié)構(gòu)查詢(xún)邊界就不再受開(kāi)發(fā)者控制。2.3 這類(lèi)漏洞為什么危險(xiǎn)很多非安全背景的讀者會(huì)想就算能改變查詢(xún)條件也查不到更多數(shù)據(jù)吧實(shí)際情況并非如此。這類(lèi)查詢(xún)接口背后的表往往不只是收貨明細(xì)本身還可能通過(guò)關(guān)聯(lián)查詢(xún)帶出供應(yīng)商主體信息、采購(gòu)訂單信息、結(jié)算數(shù)據(jù)等。SQL 注入一旦成立攻擊者可以逐步擴(kuò)大查詢(xún)范圍甚至結(jié)合數(shù)據(jù)庫(kù)自身的報(bào)文特性獲取更多內(nèi)容。真正讓它危險(xiǎn)的原因有三點(diǎn)一是數(shù)據(jù)敏感。收貨明細(xì)里包含價(jià)格、數(shù)量、供應(yīng)商賬戶(hù)信息這些數(shù)據(jù)一旦泄露可能被用于商業(yè)情報(bào)收集甚至進(jìn)一步詐騙。二是接口可達(dá)性高。receiptDetail 是高頻接口且可能出現(xiàn)在供應(yīng)商門(mén)戶(hù)、開(kāi)放 API、移動(dòng)端接口等多個(gè)入口。攻擊者不一定需要攻破后臺(tái)系統(tǒng)只要找到了一個(gè)帶有參數(shù)的查詢(xún)?nèi)肟诰涂梢試L試探測(cè)。三是數(shù)據(jù)庫(kù)權(quán)限往往過(guò)大。很多老系統(tǒng)的數(shù)據(jù)庫(kù)賬號(hào)是應(yīng)用賬號(hào)直連權(quán)限大多很大甚至具備寫(xiě)文件、調(diào)用系統(tǒng)命令等高危權(quán)限。SQL 注入一旦配合這類(lèi)權(quán)限就不再只是數(shù)據(jù)查詢(xún)問(wèn)題可能演變?yōu)榉?wù)器層面的嚴(yán)重風(fēng)險(xiǎn)。3. 本地靶場(chǎng)復(fù)現(xiàn)與 POC 驗(yàn)證思路3.1 搭一個(gè)能放心驗(yàn)證的隔離環(huán)境復(fù)現(xiàn)這類(lèi)漏洞前提是獲得合法授權(quán)并且在隔離的本地環(huán)境中進(jìn)行。我不建議任何人拿線(xiàn)上系統(tǒng)直接試驗(yàn)這一點(diǎn)必須放在最前面說(shuō)。我當(dāng)時(shí)的做法是在一臺(tái)本地虛擬機(jī)里用 Docker 搭建了一套最小復(fù)現(xiàn)環(huán)境只保留和漏洞相關(guān)的基礎(chǔ)組件。環(huán)境清單大致如下組件選型說(shuō)明應(yīng)用框架Spring Boot 2.x MyBatis模擬真實(shí)查詢(xún)接口的請(qǐng)求鏈路數(shù)據(jù)庫(kù)MySQL 8.0用來(lái)觀察 SQL 執(zhí)行行為和報(bào)錯(cuò)信息樣例數(shù)據(jù)100 條左右模擬收貨單明細(xì)保證查詢(xún)有正常、空集、報(bào)錯(cuò)三種響應(yīng)場(chǎng)景測(cè)試工具瀏覽器 DevTools Python 腳本手工驗(yàn)證探針行為和后續(xù)自動(dòng)化回歸數(shù)據(jù)庫(kù)里準(zhǔn)備了模擬數(shù)據(jù)每張明細(xì)都包含收貨單 ID、物料編碼、數(shù)量、單價(jià)、供應(yīng)商編碼等字段。這里需要注意靶場(chǎng)數(shù)據(jù)不要直接用真實(shí)脫敏數(shù)據(jù)最好完全隨機(jī)生成避免合規(guī)風(fēng)險(xiǎn)。環(huán)境啟動(dòng)后第一步是發(fā)起正常查詢(xún)請(qǐng)求確認(rèn)接口的基礎(chǔ)功能和響應(yīng)結(jié)構(gòu)。比如請(qǐng)求GET /api/receipt/detail?id1001page1size10正常響應(yīng)會(huì)返回一條或多條明細(xì)記錄。記錄下響應(yīng)體的長(zhǎng)度和業(yè)務(wù)字段后續(xù)所有驗(yàn)證都會(huì)拿這一步的結(jié)果做參照。3.2 注入點(diǎn)定位從一口“報(bào)錯(cuò)”說(shuō)起我定位注入點(diǎn)的過(guò)程可以分為四步每一步都非常簡(jiǎn)單但每一步都有明確的判斷目標(biāo)。第一步請(qǐng)求正常參數(shù)。正常獲取 id1001 的響應(yīng)確認(rèn)接口行為是穩(wěn)定查詢(xún)。第二步在參數(shù)末尾追加一個(gè)單引號(hào)。如果原來(lái)的查詢(xún)條件寫(xiě)法是WHERE id ${id}那么單引號(hào)會(huì)讓 SQL 的字符串閉合出現(xiàn)錯(cuò)亂數(shù)據(jù)庫(kù)往往直接報(bào)語(yǔ)法錯(cuò)誤。響應(yīng)中可能會(huì)出現(xiàn) 500 狀態(tài)碼錯(cuò)誤頁(yè)面里可能直接暴露原始 SQL 或數(shù)據(jù)庫(kù)異常信息。這一步的意義是確認(rèn)參數(shù)是否被原樣拼入了 SQL。第三步字符型布爾驗(yàn)證。把 id 換成1001 AND 11如果返回值與正常請(qǐng)求一致說(shuō)明 SQL 中的條件被成功吸收額外條件恒真且沒(méi)有破壞整體語(yǔ)句。第四步恒假條件驗(yàn)證。把 id 換成1001 AND 12如果返回值變成空集或返回記錄數(shù)明顯變化說(shuō)明參數(shù)已經(jīng)參與邏輯判斷。到這一步基本可以判斷該參數(shù)存在可被利用的 SQL 注入風(fēng)險(xiǎn)。需要說(shuō)明的是這里展示的探針只是用于確認(rèn)風(fēng)險(xiǎn)是否存在并不涉及任何數(shù)據(jù)獲取行為。全部驗(yàn)證都在本地靶場(chǎng)完成生產(chǎn)系統(tǒng)和未授權(quán)目標(biāo)一律不允許做類(lèi)似操作。3.3 設(shè)計(jì)一個(gè)輕量的 POC 腳本確認(rèn)注入點(diǎn)存在后我寫(xiě)了一個(gè)最小化的驗(yàn)證腳本用途不是攻擊而是固化驗(yàn)證邏輯方便后續(xù)回歸時(shí)反復(fù)使用。腳本的思路非常簡(jiǎn)單對(duì)同一參數(shù)同時(shí)發(fā)起正常請(qǐng)求、恒真條件請(qǐng)求、恒假條件請(qǐng)求對(duì)比三組響應(yīng)的長(zhǎng)度和狀態(tài)碼就能自動(dòng)判斷是否存在字符型注入風(fēng)險(xiǎn)。以下腳本只適合在本地授權(quán)靶場(chǎng)中使用 本地靶場(chǎng) SQL 注入布爾探針腳本 僅用于授權(quán)環(huán)境下的漏洞確認(rèn)和安全回歸測(cè)試嚴(yán)禁對(duì)未授權(quán)系統(tǒng)使用 import requests BASE_URL http://127.0.0.1:8080/api/receipt/detail TARGET_ID 1001 def build_params(pid): normal {id: pid, page: 1, size: 10} # 恒真條件用于確認(rèn)請(qǐng)求是否能被正常吸收 true_cond {id: f{pid} AND 11, page: 1, size: 10} # 恒假條件用于確認(rèn)是否參與查詢(xún)邏輯 false_cond {id: f{pid} AND 12, page: 1, size: 10} return normal, true_cond, false_cond def probe(pid): normal, true_cond, false_cond build_params(pid) results [] for params in (normal, true_cond, false_cond): try: resp requests.get(BASE_URL, paramsparams, timeout5) results.append((resp.status_code, len(resp.text))) except Exception as exc: results.append((0, str(exc))) return results if __name__ __main__: ret probe(TARGET_ID) normal_len ret[0][1] true_len ret[1][1] false_len ret[2][1] print(fnormal: {ret[0]}) print(ftrue: {ret[1]}) print(ffalse: {ret[2]}) # 若恒真與正常響應(yīng)存在一致特征而恒假響應(yīng)明顯變短或變空則說(shuō)明條件已生效 if false_len normal_len: print(疑似存在字符型 SQL 注入風(fēng)險(xiǎn)請(qǐng)結(jié)合人工判斷) else: print(未發(fā)現(xiàn)明顯差異請(qǐng)檢查是否存在其它拼接點(diǎn))腳本本身很短但設(shè)計(jì)上考慮了三點(diǎn)一是所有請(qǐng)求都帶超時(shí)防止資源占用二是只比較響應(yīng)長(zhǎng)度不做數(shù)據(jù)獲取三是輸出結(jié)果不依賴(lài)具體業(yè)務(wù)字段可以快速接入后續(xù)的自動(dòng)化回歸流程。在實(shí)際復(fù)現(xiàn)過(guò)程中我還建議把三組請(qǐng)求的完整響應(yīng)保存下來(lái)尤其是真實(shí)請(qǐng)求和恒假請(qǐng)求的差異。如果恒假請(qǐng)求返回空列表或者條目明顯減少說(shuō)明條件已經(jīng)生效直接定位問(wèn)題的證據(jù)就有了。4. 修復(fù)方案與縱深防御實(shí)踐4.1 根因修復(fù)從 ${} 到 #{} 不只是改一個(gè)符號(hào)修復(fù) SQL 注入最徹底的方法永遠(yuǎn)是消除 SQL 字符串拼接使用參數(shù)化查詢(xún)。對(duì) MyBatis 來(lái)說(shuō)就是把${}替換成#{}。把前面那段有問(wèn)題的 XML 改掉后應(yīng)當(dāng)是select idqueryList resultTypemap SELECT * FROM receipt_detail WHERE id #{id} ORDER BY create_time DESC LIMIT #{offset}, #{size} /select注意這里有兩個(gè)細(xì)節(jié)第一#{}生成的是預(yù)編譯占位符參數(shù)會(huì)在執(zhí)行階段由驅(qū)動(dòng)安全傳值不會(huì)改變 SQL 結(jié)構(gòu)。JDBC 層面會(huì)自動(dòng)處理轉(zhuǎn)義單引號(hào)、反斜杠等特殊字符都只是字符串內(nèi)容不會(huì)再被當(dāng)作 SQL 語(yǔ)法元素。第二改造過(guò)程中容易踩坑的是動(dòng)態(tài)條件。比如常見(jiàn)查詢(xún)里按訂單號(hào)、供應(yīng)商編碼、狀態(tài)等字段做動(dòng)態(tài)拼接如果改造不完整改造后的接口依然會(huì)有遺漏的拼接點(diǎn)。最穩(wěn)妥的做法是把查詢(xún)語(yǔ)句里所有參數(shù)都過(guò)一遍凡是可能被外部輸入的一律使用#{}占位。另外LIKE 模糊查詢(xún)的場(chǎng)景要注意寫(xiě)法。比如查詢(xún)收貨備注信息select idqueryByKeyword resultTypemap SELECT * FROM receipt_detail WHERE remark LIKE CONCAT(%, #{keyword}, %) /select不要把參數(shù)直接拼進(jìn)%${keyword}%。使用CONCAT函數(shù)把模糊查詢(xún)的特殊字符和參數(shù)分開(kāi)傳參既安全又保持查詢(xún)語(yǔ)義。動(dòng)態(tài)排序字段是另一個(gè)常見(jiàn)遺漏點(diǎn)。比如ORDER BY ${sortField}排序字段名無(wú)法使用占位符需要通過(guò)白名單方式解決。正確做法是String sortField create_time; // 默認(rèn)值 if (update_time.equals(param.getSortField())) { sortField update_time; } else if (quantity.equals(param.getSortField())) { sortField quantity; }只有白名單里明確的字段名才允許進(jìn)入 SQL 文本。外部傳入的任何其他字段名一律使用默認(rèn)值。4.2 接口層、數(shù)據(jù)層、配置層的組合拳根因修復(fù)雖然解決了注入本身但為了確保系統(tǒng)整體安全還需要做幾層加固。這里有一個(gè)觀念上的變化安全不是只修一個(gè)漏洞而是要讓同類(lèi)問(wèn)題在后續(xù)迭代中盡量少出現(xiàn)。接口層要做的事有三件一是參數(shù)校驗(yàn)。請(qǐng)求參數(shù)進(jìn)入控制器后第一時(shí)間做類(lèi)型和取值校驗(yàn)。id 應(yīng)當(dāng)是數(shù)字類(lèi)型receiptType 應(yīng)當(dāng)在系統(tǒng)預(yù)定義的枚舉范圍內(nèi)。不符合格式的直接返回 400不再進(jìn)入業(yè)務(wù)邏輯。二是數(shù)據(jù)權(quán)限校驗(yàn)。收貨明細(xì)查詢(xún)不能只依賴(lài) SQL 條件。Service 層需要根據(jù)當(dāng)前登錄用戶(hù)所屬供應(yīng)商或采購(gòu)組織把可查詢(xún)的范圍限制住。這部分邏輯放在業(yè)務(wù)代碼里比 SQL 條件更可控。三是返回字段最小化。接口只返回前端必要的字段不要把整行數(shù)據(jù)的所有字段都附帶返回。減少數(shù)據(jù)暴露面可以降低單次接口被異常調(diào)用時(shí)的損失。數(shù)據(jù)層的加固重點(diǎn)在數(shù)據(jù)庫(kù)賬號(hào)權(quán)限。業(yè)務(wù)應(yīng)用對(duì)應(yīng)的數(shù)據(jù)庫(kù)賬號(hào)原則上只保留查詢(xún)和必要寫(xiě)入權(quán)限。報(bào)表查詢(xún)類(lèi)賬號(hào)可以單獨(dú)建立只讀賬號(hào)避免應(yīng)用被注入時(shí)擁有過(guò)高權(quán)限。數(shù)據(jù)庫(kù)賬號(hào)也不要啟用文件讀寫(xiě)、命令執(zhí)行等高級(jí)權(quán)限這類(lèi)權(quán)限在實(shí)際業(yè)務(wù)中大多用不到。配置層的加固主要是網(wǎng)關(guān)和 WAF。在系統(tǒng)入口處加上基礎(chǔ)注入特征攔截規(guī)則比如包含明顯恒真條件、數(shù)據(jù)庫(kù)注釋符、報(bào)錯(cuò)函數(shù)特征的請(qǐng)求直接拒絕。但這里必須說(shuō)一句WAF 是兜底手段不是根本解決方案。它能攔截掉一部分已知特征卻很難完全擋住精心構(gòu)造的繞行語(yǔ)法。真正能兜住底的是代碼里不再出現(xiàn)拼接點(diǎn)。4.3 修復(fù)后的驗(yàn)證與回歸修復(fù)完成后需要重新走一遍驗(yàn)證流程。我習(xí)慣用一張簡(jiǎn)單的對(duì)照表來(lái)梳理測(cè)試場(chǎng)景構(gòu)造輸入預(yù)期結(jié)果正常路徑id1001page1size10正常返回明細(xì)數(shù)據(jù)恒真條件id1001 AND 11返回正常數(shù)據(jù)與恒真條件無(wú)關(guān)恒假條件id1001 AND 12不因?yàn)楹慵贄l件而返回空集非法類(lèi)型參數(shù)idabc返回參數(shù)校驗(yàn)錯(cuò)誤排序字段異常sortFieldid; DROP TABLE不生效回退默認(rèn)排序驗(yàn)證時(shí)不要只看 HTTP 狀態(tài)碼和前端表現(xiàn)一定要打開(kāi)數(shù)據(jù)庫(kù)日志。觀察數(shù)據(jù)庫(kù)實(shí)際收到的 SQL 語(yǔ)句。如果日志中出現(xiàn)id 1001這樣帶引號(hào)的值說(shuō)明參數(shù)是通過(guò)占位符傳入的如果出現(xiàn)拼接后的完整 SQL說(shuō)明鏈路上還有殘留拼接點(diǎn)需要繼續(xù)排查。回歸驗(yàn)證還要覆蓋原有業(yè)務(wù)場(chǎng)景。改動(dòng) SQL 后正常查詢(xún)、分頁(yè)、排序、導(dǎo)出等原有功能需要重新執(zhí)行一遍防止因?yàn)閰?shù)化改造破壞業(yè)務(wù)邏輯。尤其是分頁(yè)接口如果查詢(xún)條件發(fā)生變化分頁(yè)總數(shù)的返回可能會(huì)不符合預(yù)期需要仔細(xì)核對(duì)。把上面提到的驗(yàn)證用例固化下來(lái)放到接口測(cè)試用例集里。以后每次發(fā)布新版本只要運(yùn)行一遍就能在最短時(shí)間內(nèi)發(fā)現(xiàn) SQL 拼接是否回歸。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 復(fù)現(xiàn)時(shí)響應(yīng)不符合預(yù)期問(wèn)題出在哪復(fù)現(xiàn)過(guò)程看起來(lái)簡(jiǎn)單實(shí)際操作中很容易碰壁。最典型的幾個(gè)問(wèn)題第一參數(shù)編碼問(wèn)題。直接通過(guò)瀏覽器地址欄輸入 AND 11時(shí)部分字符可能被瀏覽器自動(dòng)編碼或者被中間件截?cái)唷Ｓ绕涫?符號(hào)URL 定位符與其后面的文本通常不會(huì)被發(fā)送到服務(wù)器因此注釋類(lèi)字符必須做 URL 編碼否則測(cè)試結(jié)果就不真實(shí)。第二請(qǐng)求方法不一致。有的查詢(xún)接口只接收 POST 請(qǐng)求參數(shù)放在請(qǐng)求體里用 GET 方式的探針自然毫無(wú)反應(yīng)。正確的做法是先抓取真實(shí)前端請(qǐng)求確認(rèn)請(qǐng)求方法和請(qǐng)求體格式再在同樣格式下構(gòu)造探針。第三數(shù)據(jù)庫(kù)錯(cuò)誤信息被屏蔽。有些系統(tǒng)的全局異常處理器把數(shù)據(jù)庫(kù)報(bào)錯(cuò)統(tǒng)一轉(zhuǎn)換成通用提示即使探針觸發(fā)了語(yǔ)法錯(cuò)誤響應(yīng)里也看不到任何 SQL 痕跡。這時(shí)不能只依賴(lài)報(bào)錯(cuò)信號(hào)還要結(jié)合布爾條件響應(yīng)差異來(lái)判斷。我的排查思路很簡(jiǎn)單先把真實(shí)請(qǐng)求完整抓包確認(rèn)參數(shù)位置和編碼格式再在靶場(chǎng)環(huán)境里調(diào)整探針格式一項(xiàng)項(xiàng)排查直到能穩(wěn)定復(fù)現(xiàn)。5.2 修完仍然被掃描器報(bào)漏洞怎么排查這是很多團(tuán)隊(duì)修復(fù)后最頭疼的問(wèn)題。代碼已經(jīng)改成了#{}但安全掃描報(bào)告依然告警。我遇到過(guò)的原因主要有三類(lèi)。第一類(lèi)接口內(nèi)部存在多個(gè)拼接點(diǎn)只改了一處。一個(gè)接口可能同時(shí)支持多個(gè)查詢(xún)參數(shù)改造時(shí)只處理了注入明顯的字段其他字段仍是${}。掃描器發(fā)往不同參數(shù)立即又能測(cè)出問(wèn)題。排查方法是把接口所有參數(shù)都過(guò)一遍逐一確認(rèn)。第二類(lèi)動(dòng)態(tài) SQL 的視圖或存儲(chǔ)過(guò)程存在拼接。如果查詢(xún)走的是數(shù)據(jù)庫(kù)視圖、存儲(chǔ)過(guò)程而視圖或存儲(chǔ)過(guò)程內(nèi)部使用了動(dòng)態(tài)執(zhí)行語(yǔ)句即使應(yīng)用層已改掉底層仍可能在執(zhí)行過(guò)程中拼接。這種情況需要把數(shù)據(jù)庫(kù)端對(duì)象和日志結(jié)合起來(lái)排查。第三類(lèi)其他代碼路徑調(diào)用同一個(gè) Mapper。Mapper 方法可能被多個(gè)控制器使用修復(fù)時(shí)只關(guān)注了其中一個(gè)入口但另一個(gè)入口依然傳入未經(jīng)過(guò)濾的字符串。建議全局搜索該 Mapper 方法的所有調(diào)用位置逐一確認(rèn)。排查技巧還是回到日志。修復(fù)后重新復(fù)現(xiàn)一次把數(shù)據(jù)庫(kù)端實(shí)際執(zhí)行的 SQL 全部打印出來(lái)逐條核對(duì)。既然掃描器能測(cè)出來(lái)就說(shuō)明某處一定存在拼接通過(guò)日志可以快速鎖定。5.3 這類(lèi)漏洞的優(yōu)先級(jí)判斷修復(fù)資源有限時(shí)不能所有接口平均用力。判斷優(yōu)先級(jí)可以從三個(gè)維度出發(fā)。一是數(shù)據(jù)敏感度。receiptDetail 這類(lèi)接口返回價(jià)格、數(shù)量、供應(yīng)商信息敏感度很高應(yīng)當(dāng)優(yōu)先修復(fù)。如果接口還關(guān)聯(lián)出賬務(wù)、合同等更高敏感字段優(yōu)先級(jí)再往上提。二是暴露面大小。接口是否被供應(yīng)商門(mén)戶(hù)、移動(dòng)端、開(kāi)放 API 等多個(gè)入口調(diào)用是否不需要復(fù)雜權(quán)限就能訪問(wèn)。暴露面越大修復(fù)優(yōu)先級(jí)越高。三是利用難度。攻擊者利用該接口獲取數(shù)據(jù)是否需要滿(mǎn)足額外條件比如是否依賴(lài)特定賬號(hào)、是否需要繞過(guò)網(wǎng)關(guān)白名單。如果利用條件很低說(shuō)明風(fēng)險(xiǎn)更容易被觸發(fā)應(yīng)當(dāng)放在更前面處理。結(jié)合這三個(gè)維度采購(gòu)系統(tǒng)中的高頻查詢(xún)接口通常處于優(yōu)先修復(fù)的位置。修復(fù)完成之后也別松勁把驗(yàn)證用例和回歸流程沉淀下來(lái)讓這類(lèi)問(wèn)題在團(tuán)隊(duì)中形成固定檢查項(xiàng)。最后分享一個(gè)我自己的習(xí)慣。修復(fù)完注入類(lèi)漏洞之后我不會(huì)刪掉驗(yàn)證用的探針腳本而是會(huì)把它改造為最小化的回歸測(cè)試用例放進(jìn)日常安全測(cè)試中。每次業(yè)務(wù)迭代跑一遍只要有人不小心把參數(shù)重新拼進(jìn) SQL它會(huì)立刻發(fā)出信號(hào)。SQL 注入不一定是技術(shù)難度最高的漏洞但它對(duì)業(yè)務(wù)數(shù)據(jù)的威脅非常直接尤其是采購(gòu)系統(tǒng)這種貼著價(jià)格、合同、供應(yīng)商資金信息走的業(yè)務(wù)一次注入引發(fā)的風(fēng)險(xiǎn)往往不會(huì)只停留在單個(gè)接口而是可能波及多個(gè)關(guān)聯(lián)系統(tǒng)。在開(kāi)發(fā)階段多用十分鐘做預(yù)編譯比上線(xiàn)后再去追生產(chǎn)事故要?jiǎng)澦愕枚唷?