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