批量操作接口這東西開(kāi)發(fā)人都熟。后臺(tái)管理系統(tǒng)里“批量導(dǎo)出”“全選刪除”“批量改狀態(tài)”滿屏都是看起來(lái)平平無(wú)奇卻是我做安全測(cè)試時(shí)最容易挖出高危漏洞的富礦。批量操作接口的邏輯漏洞從來(lái)不在堆棧溢出或SQL注入這種“硬傷”里找它藏在業(yè)務(wù)流程最順滑的地方一個(gè)接口同時(shí)處理多條數(shù)據(jù)權(quán)限校驗(yàn)卻還默認(rèn)“你會(huì)遵守規(guī)則”。這篇文章不談教科書(shū)理論就拆解批量接口在設(shè)計(jì)、測(cè)試、修復(fù)過(guò)程中真正會(huì)踩的坑以及我為什么說(shuō)這類漏洞比傳統(tǒng)注入更值得重視。這篇文章適合后端開(kāi)發(fā)、安全研發(fā)、測(cè)試工程師甚至對(duì)接口設(shè)計(jì)感興趣的架構(gòu)師。讀完之后你能快速識(shí)別自己系統(tǒng)里批量接口是否存在同類問(wèn)題也能直接拿來(lái)當(dāng)自查清單用。1. 批量接口的基礎(chǔ)設(shè)計(jì)與安全邊界1.1 批量操作的業(yè)務(wù)場(chǎng)景與接口形態(tài)批量接口并不是什么新鮮概念。凡是前臺(tái)要一次處理多條數(shù)據(jù)的場(chǎng)景后臺(tái)幾乎都逃不開(kāi)三種形態(tài)第一種是逐條循環(huán)型。前端做多個(gè)請(qǐng)求接口本身不感知“批量”。這種形態(tài)沒(méi)什么討論價(jià)值它就是單條接口的重復(fù)調(diào)用邏輯漏洞通常和普通接口一致。第二種是批量參數(shù)型。前端傳一個(gè)數(shù)組比如{ ids: [1001, 1002, 1003], action: delete }后端拿到數(shù)組后統(tǒng)一處理。這是最常見(jiàn)的批量接口形態(tài)也是邏輯漏洞重災(zāi)區(qū)。第三種是批量任務(wù)型。接口只創(chuàng)建一條“批量任務(wù)”比如“導(dǎo)入10000個(gè)用戶”實(shí)際執(zhí)行是異步的通過(guò)消息隊(duì)列或后臺(tái)任務(wù)逐條落地。形態(tài)不同暴露的攻擊面也不同。第二種最容易出現(xiàn)越權(quán)和參數(shù)篡改問(wèn)題第三種最容易出現(xiàn)資源耗盡和競(jìng)態(tài)問(wèn)題。理解接口是哪種形態(tài)是分析邏輯漏洞的第一步。因?yàn)楹芏喟踩珕?wèn)題上你連檢查對(duì)象都搞錯(cuò)了。1.2 邏輯漏洞在批量場(chǎng)景下為何被放大單條接口的邏輯漏洞影響面通?？煽亍５瑯拥穆┒窗岬脚拷涌诶镂：χ苯映艘粋€(gè)系數(shù)。舉個(gè)我實(shí)際遇到的例子。一個(gè)“批量預(yù)覽”接口接收多個(gè)文件ID返回文件的預(yù)覽頁(yè)URL。按設(shè)計(jì)文檔這個(gè)接口要求傳入的每個(gè)文件都?xì)w屬于當(dāng)前登錄用戶。但服務(wù)端只校驗(yàn)了“當(dāng)前用戶是否登錄”沒(méi)有校驗(yàn)“文件ID是否屬于當(dāng)前用戶”。這就是典型的IDOR不安全的直接對(duì)象引用問(wèn)題。單查一個(gè)文件只是信息泄露批量查詢就直接變成了拖庫(kù)利器——攻擊者把ID從1遍歷到10萬(wàn)一次傳200個(gè)ID幾十個(gè)請(qǐng)求就把全站文件元信息拿走了。類似的還有批量導(dǎo)出接口。單條導(dǎo)出你可能還能通過(guò)文件名、權(quán)限標(biāo)識(shí)判斷用戶越權(quán)但批量接口為了性能服務(wù)端往往先把符合條件的記錄查出來(lái)再統(tǒng)一打包這個(gè)查詢條件如果沒(méi)拼上“當(dāng)前用戶ID”導(dǎo)出的就是整個(gè)業(yè)務(wù)表。所以一個(gè)核心認(rèn)知要說(shuō)清楚邏輯漏洞不是批量接口獨(dú)有但批量接口讓邏輯漏洞的危害呈數(shù)量級(jí)放大。這也是安全圈把它單獨(dú)拿出來(lái)討論的原因。2. 批量操作接口的典型邏輯漏洞拆解2.1 越權(quán)漏洞從垂直越權(quán)到水平越權(quán)的批量放大越權(quán)是我在批量接口里見(jiàn)到最多的邏輯漏洞可以分為兩類水平越權(quán)同級(jí)用戶之間越權(quán)。比如A用戶通過(guò)批量接口操作B用戶的數(shù)據(jù)。典型的場(chǎng)景是“批量更新任務(wù)狀態(tài)”接口傳入任務(wù)ID數(shù)組對(duì)這些任務(wù)做“完成”操作。如果服務(wù)端沒(méi)有校驗(yàn)每個(gè)任務(wù)ID是否歸屬當(dāng)前用戶A就能把B的待辦任務(wù)全部標(biāo)記完成——這不只是信息泄露已經(jīng)是對(duì)業(yè)務(wù)的直接破壞。垂直越權(quán)低權(quán)限用戶執(zhí)行高權(quán)限操作。常見(jiàn)于“批量刪除用戶”“批量配置權(quán)限”“批量審核”這類管理類接口。服務(wù)端只校驗(yàn)了登錄態(tài)沒(méi)校驗(yàn)角色權(quán)限普通用戶直接調(diào)用管理端批量接口完成管理員才能做的操作。我印象最深的一次測(cè)試是給某內(nèi)容管理系統(tǒng)的“批量移動(dòng)文章分類”接口做檢查。這個(gè)接口接收文章ID數(shù)組和目標(biāo)分類ID測(cè)試時(shí)發(fā)現(xiàn)只要登錄就能調(diào)用完全不校驗(yàn)當(dāng)前用戶是否為文章所屬項(xiàng)目的成員。我切換到一個(gè)剛創(chuàng)建的低權(quán)限測(cè)試賬號(hào)把別人項(xiàng)目下的文章移到了自己的分類里。這不是測(cè)試數(shù)據(jù)是真實(shí)數(shù)據(jù)好在漏洞及時(shí)提交后很快就修復(fù)了。這類漏洞的邏輯核心只有一個(gè)詞信任。服務(wù)端默認(rèn)調(diào)用者是經(jīng)過(guò)前端菜單、按鈕權(quán)限過(guò)濾后的正常用戶默認(rèn)傳入的數(shù)據(jù)都在調(diào)用者可控范圍內(nèi)?？山涌谝坏╅_(kāi)放給外部或惡意腳本這種信任就變成致命傷。2.2 冪等性缺失與重復(fù)提交問(wèn)題批量接口天然面臨一個(gè)困境客戶端不確定一批操作是否成功于是選擇重試。如果接口不冪等重試就會(huì)變成重復(fù)執(zhí)行。批量扣減庫(kù)存、批量發(fā)放優(yōu)惠券、批量轉(zhuǎn)賬——這類有副作用的批量操作一旦缺少冪等保護(hù)后果很直接用戶點(diǎn)了一次“確定”按鈕網(wǎng)絡(luò)抖動(dòng)導(dǎo)致前端超時(shí)重發(fā)優(yōu)惠券發(fā)了雙份或者更嚴(yán)重測(cè)試腳本對(duì)同一個(gè)“批量退款”接口重放了三次用戶收到三筆退款。冪等性的實(shí)現(xiàn)不是加個(gè)去重表那么簡(jiǎn)單。批量接口的冪等設(shè)計(jì)需要考慮“部分失敗”的情況一批20條數(shù)據(jù)前10條處理成功第11條失敗整個(gè)請(qǐng)求返回失敗——前端收到失敗后重試這20條又要處理一遍。前10條會(huì)不會(huì)被重復(fù)處理完全取決于每條數(shù)據(jù)的業(yè)務(wù)邏輯有沒(méi)有做重復(fù)判斷。我之前建議團(tuán)隊(duì)在批量接口里引入冪等鍵Idempotency Key機(jī)制客戶端在提交批量操作時(shí)生成一個(gè)唯一請(qǐng)求ID服務(wù)端用這個(gè)ID做去重。這個(gè)方案很多開(kāi)源系統(tǒng)已經(jīng)在用并且是放入請(qǐng)求頭或請(qǐng)求體中都行關(guān)鍵是服務(wù)端要原子地檢查記錄、標(biāo)記已用。否則還是有競(jìng)態(tài)窗口。2.3 競(jìng)態(tài)條件批量接口的“并發(fā)幽靈”競(jìng)態(tài)條件在單條接口也有但批量場(chǎng)景會(huì)有獨(dú)特的放大效應(yīng)。典型是先檢查后使用TOCTOU, Time of Check to Time of Use模式。舉一個(gè)經(jīng)典的批量搶購(gòu)案例接口接收商品ID數(shù)組每次購(gòu)買多件庫(kù)存。業(yè)務(wù)邏輯是“先檢查庫(kù)存夠不夠夠了再扣減”。如果兩個(gè)請(qǐng)求幾乎同時(shí)到達(dá)都通過(guò)了庫(kù)存檢查然后各自扣減庫(kù)存就變成負(fù)數(shù)了。這不是理論推演而是我在某電商平臺(tái)的秒殺系統(tǒng)中真實(shí)看到過(guò)的問(wèn)題只是他們用了分布式鎖做保護(hù)沒(méi)出事故而已。另一個(gè)容易被忽視的競(jìng)態(tài)場(chǎng)景是批量狀態(tài)流轉(zhuǎn)?！芭繉徍送ㄟ^(guò)”接口先查詢一批訂單狀態(tài)為“待審核”然后逐條修改為“已審核”。如果同一時(shí)間另一個(gè)運(yùn)維腳本正把這些訂單改為“已駁回”兩個(gè)操作交叉執(zhí)行最終狀態(tài)就取決于最后執(zhí)行的那條SQL而不是業(yè)務(wù)預(yù)期。批量接口的并發(fā)測(cè)試不像普通接口那么好測(cè)。單個(gè)請(qǐng)求慢放不夠要用多線程并發(fā)才能觸發(fā)。做安全測(cè)試時(shí)我常用一個(gè)簡(jiǎn)單方法在服務(wù)端關(guān)鍵代碼段前加一個(gè)時(shí)間延遲比如 sleep 3秒然后同時(shí)發(fā)起多個(gè)批量請(qǐng)求。如果修改操作沒(méi)有行鎖或樂(lè)觀鎖保護(hù)幾乎必現(xiàn)狀態(tài)異常。這是調(diào)試競(jìng)態(tài)問(wèn)題的經(jīng)典手法。2.4 數(shù)據(jù)量無(wú)上限與資源耗盡這類漏洞不篡改數(shù)據(jù)卻能讓服務(wù)癱瘓。批量接口接收ID數(shù)組最常見(jiàn)的邏輯缺陷是沒(méi)有限制數(shù)組長(zhǎng)度。一個(gè)“批量導(dǎo)出用戶信息”的接口前端頁(yè)面做得很好一次最多選2000條。但接口本身不校驗(yàn)?zāi)阌肞ython腳本直接構(gòu)造一個(gè)包含20萬(wàn)個(gè)ID的數(shù)組發(fā)過(guò)去后端就開(kāi)始內(nèi)存溢出了——每查一條記錄要初始化一個(gè)對(duì)象20萬(wàn)個(gè)對(duì)象塞進(jìn)內(nèi)存列表直接OOM。更隱蔽的是數(shù)據(jù)庫(kù)層面。批量接口為了效率經(jīng)常用WHERE id IN (...)查詢這個(gè)IN列表一旦過(guò)大數(shù)據(jù)庫(kù)執(zhí)行計(jì)劃會(huì)從索引掃描退化成全表掃描甚至報(bào)錯(cuò)。另一類資源耗盡發(fā)生在批量任務(wù)型接口里用戶提交了一個(gè)導(dǎo)入任務(wù)沒(méi)有并發(fā)數(shù)限制也沒(méi)有任務(wù)隊(duì)列上限。惡意用戶循環(huán)調(diào)用接口提交10000個(gè)大規(guī)模導(dǎo)入任務(wù)后臺(tái)任務(wù)隊(duì)列直接堆爆正常業(yè)務(wù)任務(wù)全部排隊(duì)餓死。設(shè)計(jì)時(shí)加三個(gè)最基本的防護(hù)就夠了數(shù)量上限校驗(yàn)、分頁(yè)循環(huán)處理、任務(wù)隊(duì)列限流。這三個(gè)防線任何一個(gè)在資源耗盡基本不可能成功。2.5 批量操作的原子性與部分成功陷阱這是批量接口里最折磨后端開(kāi)發(fā)者的一個(gè)問(wèn)題一批操作到底應(yīng)該“全部成功”還是“全部失敗”業(yè)務(wù)語(yǔ)義上批量操作應(yīng)該是原子的。要么全成功要么全失敗。但實(shí)現(xiàn)上一條SQL或一次RPC處理20條數(shù)據(jù)很容易失敗一半。于是很多系統(tǒng)選擇了“逐條處理記錄失敗原因”返回“成功18條失敗2條”。這種設(shè)計(jì)本身沒(méi)錯(cuò)問(wèn)題出在失敗重試時(shí)會(huì)重復(fù)處理成功的那18條。我剛提到冪等性時(shí)說(shuō)過(guò)這個(gè)場(chǎng)景現(xiàn)在要補(bǔ)充的是即使有冪等鍵部分成功返回給客戶的體驗(yàn)也容易出問(wèn)題?？蛻舨恢滥?條失敗了也不知道失敗原因是什么只能對(duì)著返回結(jié)果猜。我的經(jīng)驗(yàn)是批量接口的返回格式必須包含逐條結(jié)果明細(xì)字段——每條數(shù)據(jù)的ID、是否成功、失敗原因。這樣前端能把失敗項(xiàng)單獨(dú)展示出來(lái)讓用戶重試。很多系統(tǒng)只返回一個(gè)“failed”整體標(biāo)志這是極大的交互缺陷也是很多“看起來(lái)報(bào)錯(cuò)但數(shù)據(jù)實(shí)際已經(jīng)改動(dòng)”的亂象源頭。3. 從邏輯分析到安全測(cè)試實(shí)操指南3.1 批量接口邏輯漏洞的分析路徑安全測(cè)試批量接口我一般遵循一套固定分析流程可以分享出來(lái)供參考。第一步梳理接口清單。從接口文檔或抓包中找出所有接收數(shù)組參數(shù)的接口重點(diǎn)關(guān)注返回批量數(shù)據(jù)的查詢接口和執(zhí)行寫操作的修改接口。第二步摸清業(yè)務(wù)歸屬。對(duì)每個(gè)批量接口問(wèn)兩個(gè)問(wèn)題這個(gè)接口操作的數(shù)據(jù)屬于誰(shuí)操作者應(yīng)該具有什么角色權(quán)限這兩個(gè)問(wèn)題的答案是越權(quán)測(cè)試的基準(zhǔn)線。第三步構(gòu)造越權(quán)樣本。拿一個(gè)合法用戶的請(qǐng)求手工改掉參數(shù)數(shù)組中某個(gè)ID換成另一個(gè)用戶的數(shù)據(jù)ID。然后觀察響應(yīng)差異。這個(gè)步驟不需要任何自動(dòng)化工具Postman或Burp Suite就能完成。第四步測(cè)試數(shù)據(jù)量邊界。構(gòu)造一個(gè)含1條、10條、100條、1000條、10000條數(shù)據(jù)的請(qǐng)求觀察響應(yīng)時(shí)間、內(nèi)存占用、是否報(bào)錯(cuò)、是否觸發(fā)限流。第五步檢查冪等與重放。對(duì)同一個(gè)批量寫操作請(qǐng)求重放多次觀察數(shù)據(jù)是否被重復(fù)處理。這里注意要抓原始請(qǐng)求直接重放而不是刷新頁(yè)面重新觸發(fā)。這套流程成本很低不需要知道系統(tǒng)源碼純黑盒就能發(fā)現(xiàn)大部分批量接口邏輯漏洞。有效的前提是理解業(yè)務(wù)——不懂“這個(gè)批量接口是干嘛的”你連越權(quán)ID都替換不對(duì)。3.2 越權(quán)與競(jìng)態(tài)的實(shí)戰(zhàn)測(cè)試技巧越權(quán)測(cè)試我常用一個(gè)“雙賬號(hào)對(duì)比法”準(zhǔn)備兩個(gè)互不相關(guān)的測(cè)試賬號(hào)A和B先用A賬號(hào)的接口正常請(qǐng)求數(shù)據(jù)保存請(qǐng)求包再用B賬號(hào)的Cookie替換掉請(qǐng)求包里的認(rèn)證信息只改Cookie不改參數(shù)重放請(qǐng)求。如果B賬號(hào)能正常拿到A賬號(hào)的數(shù)據(jù)水平越權(quán)就實(shí)錘了。如果還能執(zhí)行寫操作那就不只是數(shù)據(jù)泄露而是直接的數(shù)據(jù)篡改刪除了。這里有個(gè)細(xì)節(jié)容易踩坑有些系統(tǒng)的Cookie關(guān)聯(lián)著SessionSession里存了用戶ID請(qǐng)求體里的用戶標(biāo)識(shí)只是展示用。這種情況下你只換Cookie不換參數(shù)可能因?yàn)镾ession綁定反而被攔截導(dǎo)致誤判“沒(méi)有漏洞”。要排掉這個(gè)干擾需要同時(shí)觀察請(qǐng)求體和Cookie的關(guān)聯(lián)邏輯。若后端信任請(qǐng)求體里的用戶ID那換參數(shù)不換Cookie也是一種有效測(cè)試方式。競(jìng)態(tài)測(cè)試的關(guān)鍵在于找到“檢查和修改之間的窗口”。純黑盒很難精確定位這個(gè)窗口我做競(jìng)態(tài)測(cè)試時(shí)會(huì)先用量大一點(diǎn)的批量請(qǐng)求慢速重放看看有沒(méi)有重復(fù)記錄產(chǎn)生如果產(chǎn)生不了再用并發(fā)工具比如腳本并發(fā)跑同一批量接口去撞。不必一定復(fù)現(xiàn)因?yàn)檫壿嬄┒吹母?jìng)態(tài)觸發(fā)概率低但只要接口沒(méi)有數(shù)據(jù)庫(kù)層的可靠鎖這個(gè)問(wèn)題大概率是存在的。3.3 防護(hù)驗(yàn)證修復(fù)后的回歸要點(diǎn)提交一個(gè)批量接口漏洞后研發(fā)的修復(fù)方式五花八門。有的在SQL里加了AND user_id ?有的在接口入口加了if (!checkPermission())有的直接限制了數(shù)組長(zhǎng)度100條。修復(fù)后做回歸測(cè)試時(shí)別只復(fù)測(cè)原漏洞路徑還要多走兩步第一驗(yàn)證修復(fù)覆蓋面。如果SQL加了user_id過(guò)濾要用另一個(gè)用戶的ID再打一次確保過(guò)濾條件真的生效而不是只針對(duì)當(dāng)時(shí)那個(gè)測(cè)試樣本。第二驗(yàn)證修復(fù)不影響正常功能。有些團(tuán)隊(duì)趕工修復(fù)會(huì)直接給整個(gè)接口加一個(gè)強(qiáng)鑒權(quán)結(jié)果正常業(yè)務(wù)用戶的大量合法操作也被攔截了。這種情況我也不是沒(méi)遇到過(guò)最后還得協(xié)調(diào)兩邊重新調(diào)整邏輯。第三觀察日志體系是否完善。真正有效的防護(hù)不只是把請(qǐng)求擋回去還要能記錄攻擊者信息。我在驗(yàn)證修復(fù)時(shí)會(huì)查看是否留下操作日志若完全無(wú)痕建議讓研發(fā)補(bǔ)上否則下次攻擊你根本不知道漏洞被利用過(guò)。4. 真實(shí)案例復(fù)盤一個(gè)批量導(dǎo)出接口的完整排查過(guò)程4.1 從一次導(dǎo)出誤操作到越權(quán)入口去年我有一次參與某團(tuán)隊(duì)的安全巡檢目標(biāo)是一個(gè)內(nèi)部數(shù)據(jù)管理平臺(tái)的“批量導(dǎo)出報(bào)表”接口。當(dāng)時(shí)拿到接口文檔看參數(shù)列表是{ id_list: [], export_type: excel }我直覺(jué)就覺(jué)得有問(wèn)題——這里ID列表的歸屬關(guān)系設(shè)定了嗎我用兩個(gè)不同權(quán)限級(jí)別的測(cè)試賬號(hào)做了交叉測(cè)試。先用管理員賬號(hào)導(dǎo)出一張測(cè)試報(bào)表拿到正常的請(qǐng)求包然后切換到一個(gè)只具備本部門數(shù)據(jù)權(quán)限的普通賬號(hào)把這個(gè)賬號(hào)的Cookie替換到剛才的請(qǐng)求包里同時(shí)把id_list保持原封不動(dòng)點(diǎn)擊發(fā)送。返回結(jié)果毫秒級(jí)生成且文件成功下載到了。我用普通賬號(hào)打開(kāi)導(dǎo)出的Excel里面的數(shù)據(jù)竟然是另一個(gè)部門的財(cái)務(wù)數(shù)據(jù)。這個(gè)接口完全信任了調(diào)用方傳入的報(bào)表ID壓根沒(méi)有做數(shù)據(jù)歸屬校驗(yàn)。更麻煩的是這個(gè)接口支持一次導(dǎo)出5000條記錄攻擊者完全可以遍歷所有報(bào)表ID批量導(dǎo)出全平臺(tái)的財(cái)務(wù)數(shù)據(jù)。這是很標(biāo)準(zhǔn)的水平越權(quán)批量數(shù)據(jù)泄露案例問(wèn)題根源就在于服務(wù)端對(duì)批量列表中的每個(gè)元素缺失了細(xì)粒度的權(quán)限校驗(yàn)只說(shuō)“你導(dǎo)出的這個(gè)id_list長(zhǎng)度沒(méi)超上限”卻沒(méi)問(wèn)“你配擁有這些ID嗎”。4.2 競(jìng)態(tài)條件下的重復(fù)發(fā)放事故模擬另一個(gè)讓我印象深刻的案例來(lái)自一個(gè)積分系統(tǒng)的“批量發(fā)放積分”接口。業(yè)務(wù)邏輯非常簡(jiǎn)單接收用戶ID數(shù)組和積分?jǐn)?shù)值逐條給用戶加積分。我用Shadow賬號(hào)測(cè)試時(shí)發(fā)起了一個(gè)40個(gè)用戶的發(fā)放請(qǐng)求數(shù)據(jù)正常。但當(dāng)我快速重復(fù)發(fā)送同一個(gè)請(qǐng)求十幾次后發(fā)現(xiàn)每個(gè)用戶都被加了十幾倍的積分。系統(tǒng)完全沒(méi)有冪等控制也不會(huì)禁止重復(fù)請(qǐng)求。如果是真實(shí)線上環(huán)境腳本或用戶誤操作重復(fù)調(diào)用三次就能給全站用戶發(fā)放三倍積分后果是企業(yè)資產(chǎn)直接流失。這類問(wèn)題修復(fù)起來(lái)說(shuō)簡(jiǎn)單也簡(jiǎn)單說(shuō)麻煩也麻煩。簡(jiǎn)單是因?yàn)榻o每次批量發(fā)放生成一個(gè)冪等鍵數(shù)據(jù)庫(kù)冪等鍵去重就夠了麻煩是因?yàn)閮绲孺I需要業(yè)務(wù)方配合設(shè)計(jì)并且需要對(duì)唯一的冪等鍵建立唯一索引確保并發(fā)環(huán)境下不會(huì)重復(fù)插入。從這兩個(gè)真實(shí)復(fù)盤可以看到批量接口的邏輯漏洞并不是單一問(wèn)題它是不完善權(quán)限校驗(yàn)?zāi)Ｐ汀I(yè)務(wù)冪等缺失、資源防護(hù)缺位三類結(jié)構(gòu)性問(wèn)題的集中暴露。4.3 修復(fù)方案中的“權(quán)衡”與“取舍”批量接口邏輯漏洞的修復(fù)本質(zhì)上就是個(gè)系統(tǒng)工程。在越權(quán)場(chǎng)景修復(fù)首選還是服務(wù)端統(tǒng)一做歸屬校驗(yàn)。判斷邏輯要下沉到數(shù)據(jù)訪問(wèn)層自然帶出當(dāng)前操作者的可見(jiàn)范圍而不是在每個(gè)接口里手寫if判斷。我前后在兩個(gè)項(xiàng)目里做過(guò)類似改造效果最穩(wěn)定的是把“數(shù)據(jù)范圍”作為一個(gè)統(tǒng)一的查詢條件注入到數(shù)據(jù)訪問(wèn)對(duì)象中前提是系統(tǒng)已經(jīng)有一個(gè)成熟的數(shù)據(jù)權(quán)限模型。如果沒(méi)有那就只能在接口層逐個(gè)加校驗(yàn)雖然繁瑣但能解燃眉之急。在冪等場(chǎng)景最好將批量接口全部設(shè)計(jì)成“冪等操作”。給客戶端發(fā)放冪等鍵有一種通用思路直接用請(qǐng)求去重表。表結(jié)構(gòu)至少要“ID”冪等鍵和“業(yè)務(wù)主鍵”兩個(gè)字段并在“業(yè)務(wù)主鍵”上建立唯一索引。后續(xù)同一業(yè)務(wù)主鍵的重復(fù)請(qǐng)求直接返回第一次的處理結(jié)果。在資源保護(hù)場(chǎng)景限制批量數(shù)量是性價(jià)比最高的方案。我個(gè)人建議單次批量接口的數(shù)據(jù)量盡量限制在100到200條之間如果確實(shí)有上千條數(shù)據(jù)要處理應(yīng)該走異步任務(wù)不要走同步接口。再對(duì)大查詢做分頁(yè)一次查500條循環(huán)查完內(nèi)存壓力會(huì)小很多。5. 不同業(yè)務(wù)領(lǐng)域的批量接口邏輯漏洞側(cè)重點(diǎn)5.1 電商與金融資金操作是命門電商系統(tǒng)的批量接口最關(guān)鍵的敏感操作是批量退款、批量轉(zhuǎn)賬、批量?jī)?yōu)惠券發(fā)放。這三類接口掛一次都是直接的資金損失。我見(jiàn)過(guò)一次批量短信發(fā)送接口被刷的案例攻擊者拿到了一個(gè)未校驗(yàn)手機(jī)號(hào)歸屬的批量發(fā)短信接口大量發(fā)送騷擾短信最后是運(yùn)營(yíng)商主動(dòng)封掉了這個(gè)產(chǎn)品的通道。在電商和金融領(lǐng)域批量接口的設(shè)計(jì)需要比其他行業(yè)更謹(jǐn)慎資金操作場(chǎng)景必須要求二次驗(yàn)證、鑒權(quán)綁定、冪等鍵和審計(jì)日志四件事同時(shí)到位。5.2 內(nèi)容平臺(tái)與協(xié)同工具越權(quán)仍是主流內(nèi)容類平臺(tái)和協(xié)同工具批量接口的主要風(fēng)險(xiǎn)集中在數(shù)據(jù)可見(jiàn)性。批量獲取文章信息、批量下載附件、批量移動(dòng)目錄、批量修改權(quán)限這些接口一旦越權(quán)泄露的是內(nèi)容資產(chǎn)破壞的是協(xié)同關(guān)系。審核系統(tǒng)的批量審批接口需要特別小心垂直越權(quán)——普通成員能不能走這個(gè)接口把內(nèi)容審核掉很多平臺(tái)這里都缺權(quán)限點(diǎn)。5.3 后臺(tái)管理系統(tǒng)數(shù)據(jù)面最廣的安全洼地最危險(xiǎn)的還是內(nèi)部后臺(tái)管理系統(tǒng)。這類系統(tǒng)部署在內(nèi)部網(wǎng)絡(luò)開(kāi)發(fā)團(tuán)隊(duì)往往默認(rèn)“內(nèi)網(wǎng)是安全的”權(quán)限校驗(yàn)做得比外網(wǎng)系統(tǒng)松得多。“導(dǎo)出用戶表”“同步訂單狀態(tài)”“批量修改配置”這些高危批量接口往往只有一個(gè)簡(jiǎn)單的登錄態(tài)校驗(yàn)。我的建議是內(nèi)部后臺(tái)系統(tǒng)必須按最小權(quán)限原則重新審視每個(gè)批量接口并且做內(nèi)部API的訪問(wèn)審計(jì)。哪怕內(nèi)網(wǎng)再信任批量接口的邏輯漏洞也經(jīng)不起一個(gè)惡意內(nèi)部人員的利用。6. 批量接口邏輯漏洞的防御與自查清單6.1 設(shè)計(jì)階段必須回答的三個(gè)問(wèn)題設(shè)計(jì)一個(gè)批量接口前開(kāi)發(fā)人員需要前置回答三個(gè)問(wèn)題否則這個(gè)接口上線后再改就很痛苦。這三個(gè)問(wèn)題分別是**第一調(diào)用者是否有權(quán)操作這批數(shù)據(jù)**這需要明確批量接口是否逐條校驗(yàn)歸屬而不是只校驗(yàn)當(dāng)前登錄者身份。**第二這個(gè)操作是否可以重復(fù)執(zhí)行**如果業(yè)務(wù)上不允許重復(fù)接口必須具備冪等能力。**第三接收批次上限是多少**這個(gè)上限必須放到接口層做硬校驗(yàn)前端限制只是體驗(yàn)優(yōu)化不是安全控制。這三個(gè)問(wèn)題都只有“是”或“否”可以考慮清楚當(dāng)場(chǎng)確認(rèn)。如果接口文檔里對(duì)這三個(gè)問(wèn)題只字未提就要找產(chǎn)品經(jīng)理和研發(fā)負(fù)責(zé)人確認(rèn)清楚再動(dòng)工。開(kāi)發(fā)完成后還需要逐條驗(yàn)證法律上這叫盡職免責(zé)技術(shù)上是負(fù)責(zé)任的工程師素養(yǎng)。6.2 代碼審計(jì)階段的高危特征模式只盯代碼也有幾個(gè)一眼就能發(fā)現(xiàn)的高危特征。第一個(gè)特征是數(shù)組參數(shù)直接進(jìn)入SQL的IN字句。遇到這個(gè)模式務(wù)必確認(rèn)數(shù)組里的ID有沒(méi)有和當(dāng)前用戶ID做關(guān)聯(lián)過(guò)濾。如果只查出所有傳來(lái)的ID數(shù)據(jù)幾乎就是越權(quán)漏洞。第二個(gè)特征是批量寫操作沒(méi)有事務(wù)包裹。批量轉(zhuǎn)賬沒(méi)有事務(wù)包裹意味著部分成功部分失敗失敗重試時(shí)無(wú)法保證冪等數(shù)據(jù)會(huì)產(chǎn)生臟狀態(tài)。這不是應(yīng)該有的事務(wù)要不要用的問(wèn)題而是批量操作必須用事務(wù)。第三個(gè)特征是接口沒(méi)有入?yún)⑿ｒ?yàn)對(duì)象上限。就是數(shù)組能傳多大接收多大沒(méi)有任何長(zhǎng)度校驗(yàn)。這種接口在線上流量沖擊下幾乎必掛。第四個(gè)特征是批量接口和單條接口邏輯不統(tǒng)一。有些系統(tǒng)單條接口有完整的權(quán)限校驗(yàn)批量接口為了效率卻“簡(jiǎn)化”了邏輯。這種“簡(jiǎn)化”就是漏洞的溫床。6.3 批量接口的安全驗(yàn)收自查表為了方便快速落地我把批量接口的安全驗(yàn)收標(biāo)準(zhǔn)濃縮成了一張自查表。團(tuán)隊(duì)可以在接口上線前走一遍也可以在安全巡檢時(shí)直接用檢查項(xiàng)判定標(biāo)準(zhǔn)風(fēng)險(xiǎn)等級(jí)歸屬校驗(yàn)批量數(shù)據(jù)中的每個(gè)ID都校驗(yàn)了歸屬者高角色鑒權(quán)接口限制了可調(diào)用的角色/權(quán)限范圍高批量上限單次請(qǐng)求的數(shù)據(jù)條數(shù)有硬上限中冪等機(jī)制重復(fù)請(qǐng)求不會(huì)重復(fù)執(zhí)行業(yè)務(wù)高事務(wù)邊界批量操作要么全成功要么全失敗中數(shù)據(jù)量保護(hù)大查詢走分頁(yè)或異步任務(wù)中日志審計(jì)操作者、時(shí)間、參數(shù)均被記錄中錯(cuò)誤明細(xì)部分失敗時(shí)返回逐條失敗原因低這張表列的項(xiàng)目都是我在實(shí)際工作中反復(fù)踩坑后提煉出來(lái)的。標(biāo)準(zhǔn)制定時(shí)不必面面俱到但高風(fēng)險(xiǎn)的幾項(xiàng)歸屬校驗(yàn)、角色鑒權(quán)、冪等機(jī)制務(wù)必卡死一條不滿足就不許上線。以前總有人說(shuō)“安全問(wèn)題交給安全團(tuán)隊(duì)就好了”但批量接口的邏輯漏洞往往要了解業(yè)務(wù)上下文才能發(fā)現(xiàn)只有安全團(tuán)隊(duì)沒(méi)有業(yè)務(wù)大腦效率和深度都會(huì)受限制。7. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄7.1 批量請(qǐng)求時(shí)部分成功部分失敗怎么辦前端收到條數(shù)不一致的結(jié)果時(shí)不要慌亂請(qǐng)按下面的順序排查先確認(rèn)響應(yīng)體有沒(méi)有逐條返回明細(xì)字段如果有直接把失敗項(xiàng)展示給用戶并支持重新針對(duì)失敗項(xiàng)提交。如果沒(méi)有明細(xì)字段這次交互設(shè)計(jì)是有缺陷的需要找研發(fā)優(yōu)化接口格式。后端排查部分失敗問(wèn)題優(yōu)先看日志中每一條記錄的失敗異常判斷是權(quán)限不足、數(shù)據(jù)沖突還是依賴服務(wù)不可用。最常見(jiàn)的原因是并發(fā)修改沖突即同一條數(shù)據(jù)被兩個(gè)請(qǐng)求同時(shí)更新后者因版本號(hào)不匹配而失敗。如果系統(tǒng)引用了樂(lè)觀鎖注意在前端引導(dǎo)用戶刷新后重試。7.2 為什么批量導(dǎo)出的文件被截?cái)嗔诉@是數(shù)據(jù)量上限導(dǎo)致的。很多導(dǎo)出接口給Excel設(shè)置了一個(gè)限制比如每張Sheet最多65536行數(shù)據(jù)量超過(guò)時(shí)會(huì)靜默截?cái)嗷蛑苯訄?bào)錯(cuò)。少數(shù)系統(tǒng)則是在SQL中設(shè)置了LIMIT 5000或被內(nèi)存限制卡住了。排查方式抓接口的入?yún)z查導(dǎo)出的總數(shù)嘗試縮小批量范圍看看是否生成完整文件。如果是SQL語(yǔ)句帶了隱式限制讓研發(fā)按分頁(yè)導(dǎo)出并壓縮打包為多文件。7.3 并發(fā)測(cè)試時(shí)發(fā)現(xiàn)接口偶爾報(bào)500批量接口在并發(fā)場(chǎng)景下報(bào)500最常見(jiàn)的原因有三個(gè)數(shù)據(jù)庫(kù)死鎖、內(nèi)存溢出、依賴超時(shí)。死鎖會(huì)返回?cái)?shù)據(jù)庫(kù)特有的錯(cuò)誤碼內(nèi)存溢出對(duì)應(yīng)JVM或Python進(jìn)程OOM日志依賴超時(shí)則看上游服務(wù)的響應(yīng)時(shí)間。我用過(guò)的排查順序是先看錯(cuò)誤日志堆?？词悄膫€(gè)服務(wù)報(bào)的錯(cuò)再看數(shù)據(jù)庫(kù)鎖等待與慢查詢記錄最后才看服務(wù)器內(nèi)存監(jiān)控曲線。如果三者都正?？梢钥紤]是不是觸發(fā)了網(wǎng)關(guān)或限流組件把請(qǐng)求拒絕了但沒(méi)按規(guī)范格式返回錯(cuò)誤碼導(dǎo)致客戶端識(shí)別為500。7.4 一個(gè)冷知識(shí)批量接口偶爾也要敢拒絕很多系統(tǒng)為了“用戶體驗(yàn)”即使批量操作數(shù)量遠(yuǎn)超合理值也選擇硬扛到底。這種做法風(fēng)險(xiǎn)極高一個(gè)超大批量的不合法請(qǐng)求進(jìn)來(lái)如果接口沒(méi)有數(shù)量上限數(shù)據(jù)庫(kù)負(fù)載和內(nèi)存都瞬間被打滿最后影響的是整個(gè)服務(wù)的穩(wěn)定性。設(shè)計(jì)批量接口時(shí)敢于在一開(kāi)始就返回“數(shù)量超限”是一種優(yōu)雅、可靠的設(shè)計(jì)。把這個(gè)邏輯用直白的業(yè)務(wù)文案放出去用戶不一定會(huì)有抱怨因?yàn)榍岸吮緛?lái)就會(huì)限制單頁(yè)勾選數(shù)量硬扛反而是拿系統(tǒng)的命在冒險(xiǎn)。我見(jiàn)過(guò)太多訂單系統(tǒng)因?yàn)楹笈_(tái)一次“導(dǎo)出全部”把主庫(kù)打掛的例子了限制是很樸素的救火隊(duì)員。8. 寫在最后的實(shí)踐體會(huì)踩完這么多批量接口的坑后我的體會(huì)是批量操作接口的邏輯漏洞幾乎都不是因?yàn)榧夹g(shù)棧差或代碼寫得亂而是因?yàn)樵诓辉撔湃蔚牡胤竭x擇了信任在應(yīng)該校驗(yàn)的地方選擇了省略在必須限制的地方選擇了放縱。你只要認(rèn)真理解業(yè)務(wù)邊界把“當(dāng)前操作者應(yīng)該可見(jiàn)可操作哪些數(shù)據(jù)”作為一條底線去審視代碼絕大多數(shù)批量接口問(wèn)題了然于心。不管是從開(kāi)發(fā)角度自查還是從安全角度測(cè)試抓牢歸屬校驗(yàn)、冪等控制、資源限制這三件事批量接口的整體安全水位就能明顯拉高。最后分享一個(gè)小技巧我在排查批量接口問(wèn)題時(shí)習(xí)慣用一個(gè)攜帶兩個(gè)賬號(hào)信息的瀏覽器環(huán)境一個(gè)操作正常功能另一個(gè)專門改參數(shù)造異常請(qǐng)求。這也是最高效的黑盒分析模式。你裝上幾個(gè)測(cè)試賬號(hào)平時(shí)沒(méi)有漏洞就練手慢慢對(duì)批量接口的邏輯漏洞就有了本能嗅覺(jué)。