Uber 10萬美元漏洞重現(xiàn)：1個單詞改寫URL就拿到用戶數(shù)據(jù)

2016年，一名安全研究員在Uber的URL里把數(shù)字改了改，服務(wù)器直接把另一個用戶的隱私數(shù)據(jù)打包送上門。獎金：1萬美元。

這個漏洞類型叫IDOR（不安全的直接對象引用），今天依然活躍在各大漏洞賞金平臺。Private程序出價500-3000美元，Public程序偶爾飆到五位數(shù)。我最近在PortSwigger Web Academy刷到第7個訪問控制實驗，發(fā)現(xiàn)它完美復(fù)刻了Uber那次的攻擊路徑——還帶了個讓新手集體踩坑的變種。

302跳轉(zhuǎn)不是護身符

很多開發(fā)者的認知盲區(qū)在這里：看到服務(wù)器返回302重定向，就默認"數(shù)據(jù)沒泄露"。但HTTP協(xié)議沒規(guī)定跳轉(zhuǎn)響應(yīng)里不能塞內(nèi)容，瀏覽器會自動跟著Location頭走，把響應(yīng)體當垃圾扔掉。用Burp Suite（滲透測試工具）攔截一看，響應(yīng)體里躺著完整的用戶數(shù)據(jù)。

這個實驗的設(shè)計者很懂獵人心理。頁面看起來正常跳轉(zhuǎn)，狀態(tài)碼也對，大部分人掃一眼就去下一個功能點了。

實驗環(huán)境是這樣的：一個電商網(wǎng)站，登錄后訪問/my-account?id=wiener，能看到自己的訂單和API密鑰。把id改成carlos，服務(wù)器返回302跳轉(zhuǎn)到登錄頁——表面拒絕訪問，但響應(yīng)體里藏著carlos的郵箱、訂單歷史和那個值錢的API密鑰。

攻擊成本：0。工具：瀏覽器地址欄，或者curl加-L參數(shù)就能看到跳轉(zhuǎn)前的完整響應(yīng)。

為什么這個變種特別毒

經(jīng)典IDOR是"越權(quán)看到不該看的數(shù)據(jù)"，防御方加個權(quán)限檢查就解決。但這個變種繞過了常見的自動化檢測——掃描器看到302就標記為"已修復(fù)"，滲透測試報告里也可能被歸類為"低危信息泄露"而降級。

實際賞金案例里，這種"跳轉(zhuǎn)泄露"模式的定價往往比經(jīng)典IDOR更高。為什么？因為業(yè)務(wù)邏輯更隱蔽，修復(fù)優(yōu)先級被低估，存活時間更長。Uber那個案例能拿到1萬，不是因為技術(shù)難度，是因為影響面廣且利用條件極低。

我在實驗里復(fù)現(xiàn)的步驟：登錄wiener賬號→抓包看到GET /my-account?id=wiener→把URL參數(shù)改成carlos→收到302跳轉(zhuǎn)→在Burp的Proxy History里查看該條響應(yīng)的Response標簽→提取API密鑰完成實驗。

整個過程沒有繞過任何加密，沒有偽造令牌，沒有會話劫持。就是改了一個URL參數(shù)，然后記得看跳轉(zhuǎn)前的響應(yīng)體。

防御方的盲區(qū)與獵人的機會

這個漏洞能活到現(xiàn)在，根本原因是前后端對"安全響應(yīng)"的理解不一致。后端開發(fā)者想的是"鑒權(quán)失敗，重定向到登錄頁"；前端框架或瀏覽器想的是"收到302，跟著Location走"；安全測試想的是"狀態(tài)碼正確，沒有敏感數(shù)據(jù)返回"。

三方共識里唯獨漏了：HTTP響應(yīng)體在跳轉(zhuǎn)前已經(jīng)完整送達，只是沒人看。

PortSwigger給這個實驗的分類是"IDOR with data leakage in redirect responses"，屬于訪問控制漏洞的子類。他們的官方解法強調(diào)兩點：一是注意任何帶對象引用的參數(shù)（id、user_id、order_id等），二是永遠不要相信狀態(tài)碼，必須檢查響應(yīng)體的每一個字節(jié)。

我在GitHub上搜了近年公開的賞金報告，發(fā)現(xiàn)類似手法的命名混亂——有人叫"302 response body leakage"，有人叫"IDOR via redirect"，還有人直接歸類為"information disclosure"。命名不統(tǒng)一導(dǎo)致知識傳播碎片化，新手更難系統(tǒng)學(xué)習。

從實驗室到真實賞金

這個實驗的價值在于把"已知漏洞"和"真實賞金"之間的鴻溝填平了。很多初學(xué)者刷完經(jīng)典IDOR實驗，以為學(xué)會了，遇到302變種卻完全沒思路。

Uber 2016年的案例之后，同類漏洞在HackerOne和Bugcrowd的公開報告里持續(xù)出現(xiàn)。2022年某金融科技公司被曝出類似問題：修改賬單ID觸發(fā)跳轉(zhuǎn)，但響應(yīng)體泄露了其他用戶的完整信用卡號后四位和交易記錄。賞金：2500美元。

2024年某SaaS平臺的報告更典型：用戶導(dǎo)出功能存在IDOR，服務(wù)器返回302到"權(quán)限不足"頁面，但響應(yīng)體里包含其他租戶的數(shù)據(jù)庫連接字符串。賞金：4000美元。

這些案例的共同點是：技術(shù)原理 trivial（微不足道），發(fā)現(xiàn)過程依賴"手動檢查響應(yīng)體"這個習慣動作，而自動化工具普遍漏報。

對于想入坑賞金狩獵的人來說，這個實驗是個低成本的能力驗證器。不需要買域名、搭環(huán)境、寫腳本，PortSwigger賬號免費，實驗時間15分鐘。能獨立完成并理解為什么302不等于安全，算是跨過了"知道IDOR"和"能挖到IDOR"之間的那道坎。

我在實驗筆記里給自己列了條檢查清單：看到任何帶ID參數(shù)的端點，先改數(shù)字，再看響應(yīng)——不管狀態(tài)碼是什么。這個習慣來自一個血淋淋的教訓(xùn)：去年漏掉過一個類似的跳轉(zhuǎn)泄露，因為Burp的攔截模式默認只顯示最終響應(yīng)，我沒手動翻歷史記錄。

后來那個漏洞被別人報了，公開報告里寫的利用步驟和我當時試的一模一樣。就差了"點一下Proxy History"這個動作。

這個實驗的隱藏彩蛋是讓你意識到：安全測試和開發(fā)一樣，有"默認配置陷阱"。Burp的默認視圖、瀏覽器的自動跳轉(zhuǎn)、掃描器的狀態(tài)碼判斷——這些便利功能在特定場景下會成為盲區(qū)。對抗這種盲區(qū)沒有銀彈，只能靠刻意練習形成的肌肉記憶。

PortSwigger在實驗結(jié)尾的說明里寫了一句：「The vulnerability arises because the application performs access control checks after retrieving the user's data from the database」。數(shù)據(jù)先查，權(quán)限后驗，這是架構(gòu)層面的時序缺陷，不是某一行代碼的筆誤。

換句話說，修復(fù)方案不是"加302跳轉(zhuǎn)"，而是"先鑒權(quán)，再查庫"——或者至少確保鑒權(quán)失敗時，已經(jīng)查出來的數(shù)據(jù)不要塞進響應(yīng)體。

這個認知對賞金獵人也很重要。提交報告時，如果你能指出是"時序缺陷"而非"缺少檢查"，更容易拿到高評級。安全團隊的修復(fù)成本評估會不一樣：前者需要調(diào)整數(shù)據(jù)流，后者可能只是加一行if語句。

我在整理這個系列的筆記時，發(fā)現(xiàn)訪問控制漏洞的賞金定價有個規(guī)律：同樣技術(shù)原理，"能讀到數(shù)據(jù)"和"能修改數(shù)據(jù)"差一檔，"需要復(fù)雜利用鏈"和"單請求觸發(fā)"又差一檔。這個302跳轉(zhuǎn)泄露屬于"單請求讀到敏感數(shù)據(jù)"，定價通常在IDOR品類里偏上。

但具體數(shù)字看平臺、看項目、看報告質(zhì)量。有人把跳轉(zhuǎn)泄露寫成"信息泄露"拿500，有人強調(diào)"繞過訪問控制"拿3000。同一漏洞，敘事框架決定賞金天花板。

這個實驗的設(shè)計者顯然懂行。實驗描述里刻意沒提"302"或"redirect"，只寫"access control vulnerability"。新手如果沒養(yǎng)成檢查所有響應(yīng)的習慣，就會卡在這里——明明步驟都對，就是找不到API密鑰。

我第一遍也卡了10分鐘。后來重新讀題，注意到"the application contains a vulnerability"這個表述的曖昧性，才想起去翻跳轉(zhuǎn)前的響應(yīng)。

這種"題目不會告訴你關(guān)鍵線索"的設(shè)計，和真實賞金場景高度一致。生產(chǎn)環(huán)境不會給你hint（提示），漏洞描述全靠你自己從行為異常里推斷。

刷完這個實驗后，我回看了Uber 2016年的公開報告。研究員Tobias Gli?mann的描述極其簡潔：「Changing the user ID in the URL returned data of other users」。沒有技術(shù)術(shù)語，沒有工具截圖，就是陳述事實。

這種報告風格在當時很罕見。大多數(shù)賞金提交會堆砌payload（攻擊載荷）和工具輸出，生怕評審看不懂。但Tobias的寫法假設(shè)讀者懂行，反而讓影響范圍一目了然。

后來這種"極簡報告"成為某種流派——尤其在IDOR這類邏輯漏洞里，復(fù)雜的技術(shù)描述反而稀釋了嚴重性。一個數(shù)字改動就能泄露數(shù)據(jù)，這個事實本身比任何利用細節(jié)都更有沖擊力。

我在實驗復(fù)盤時嘗試模仿這種寫法：「修改URL參數(shù)id的值，服務(wù)器在302響應(yīng)體中返回其他用戶的API密鑰」。一句話說完，沒有形容詞。

對比我自己第一版筆記："通過Burp Suite攔截請求，修改id參數(shù)后發(fā)現(xiàn)雖然服務(wù)器返回302狀態(tài)碼但響應(yīng)體中仍然存在敏感數(shù)據(jù)泄露最終獲取到目標API密鑰"——信息密度差了一個數(shù)量級。

這個細節(jié)對賞金狩獵的副業(yè)屬性很重要。大多數(shù)人不是全職做安全研究，報告寫作時間有限。能一句話說清楚的漏洞，沒必要寫一頁。

實驗的最后一個關(guān)卡是提交API密鑰完成驗證。我故意試了幾次錯誤答案，發(fā)現(xiàn)系統(tǒng)給的反饋也有信息泄露：錯誤提示會區(qū)分"密鑰不存在"和"密鑰格式錯誤"。這個設(shè)計可能是無意的，但在真實系統(tǒng)里，這種細粒度的錯誤提示能幫助攻擊者枚舉有效密鑰范圍。

PortSwigger沒把這個做成正式實驗點，但我記在了筆記里。防御的盲區(qū)往往是連續(xù)的，找到一個漏洞后，周邊功能的檢查優(yōu)先級應(yīng)該自動上調(diào)。

這個系列刷到第7個實驗，我開始理解為什么訪問控制是賞金報告的大類。技術(shù)門檻不高，但覆蓋場景極廣——從URL參數(shù)到HTTP頭，從響應(yīng)體到WebSocket消息，任何攜帶對象引用的數(shù)據(jù)流都可能成為攻擊面。

而且和業(yè)務(wù)邏輯深度綁定，自動化掃描幾乎無能為力。這意味著人工測試的溢價空間長期存在，不像SQL注入或XSS那樣被工具卷到白菜價。

302跳轉(zhuǎn)泄露是這個大類里的細分品種，目前競爭還不激烈。我在HackerOne的公開報告庫里搜"redirect response body"，結(jié)果不到50條，而"IDOR"有數(shù)千條。信息不對稱就是機會窗口。

實驗的官方解法最后提醒：「Always check the response body, even for redirect responses」。我把這句話設(shè)成了Burp的啟動頁背景。每次打開工具都看到，直到形成條件反射。

這個習慣的成本是每次測試多花幾秒，收益是可能多賺幾千美元。數(shù)學(xué)上很劃算，但人性上很難堅持——因為99%的302響應(yīng)確實沒有敏感數(shù)據(jù)，那1%的例外需要你在沒有正反饋的情況下持續(xù)檢查。

賞金狩獵某種程度上是反人性的工作：長期低概率事件，單次高回報，中間沒有進度條。這個實驗的價值，是把"長期"壓縮到了15分鐘，讓你體驗完整的心流——從疑惑到發(fā)現(xiàn)到驗證到提交。

我最后檢查了一遍實驗環(huán)境的網(wǎng)絡(luò)日志，確認沒有遺漏其他攻擊面。id參數(shù)除了數(shù)字還支持字符串測試，但在這個場景下沒有額外發(fā)現(xiàn)。有些獵人會在報告里寫"經(jīng)過全面測試未發(fā)現(xiàn)其他漏洞"，我覺得多余——沒發(fā)現(xiàn)就是沒發(fā)現(xiàn)，不需要強調(diào)"全面"。

Tobias的Uber報告里完全沒有這種防御性表述。他發(fā)現(xiàn)了什么就寫什么，沒發(fā)現(xiàn)的不提。這種自信來自對漏洞價值的準確判斷，不需要用工作量來背書。

我在整理這個系列的GitHub倉庫時，給每個實驗打了標簽。這個的標簽是：idor, redirect, response-body, beginner-friendly, real-world-impact。最后一個標簽是我加的，因為PortSwigger官方?jīng)]提Uber案例，但我覺得對學(xué)習者很重要——知道某個技能能換錢，學(xué)習動力會不一樣。

實驗完成后的證書頁面有個細節(jié)：系統(tǒng)記錄了你完成的時間，但不顯示排名或百分比。這種設(shè)計避免了"刷速度"的內(nèi)卷，讓學(xué)習者專注于理解而非競爭。

但我在Twitter上搜這個實驗的hashtag，發(fā)現(xiàn)有人曬5分鐘完成的截圖。這種炫耀性分享是社區(qū)文化的一部分，雖然和官方意圖相悖。我花了15分鐘，其中10分鐘卡在沒檢查響應(yīng)體——這個彎路反而讓我印象更深。

最后把API密鑰粘貼到提交框時，我注意到輸入框有前端長度限制，但后端驗證更寬松。這個不一致性可能是另一個漏洞入口，但超出了實驗范圍。我記在了待測試清單里，等刷完整個訪問控制系列再回來看。

漏洞狩獵的待辦清單永遠清不完，這是這個領(lǐng)域的魅力也是詛咒。你永遠不知道下一個重大發(fā)現(xiàn)是在計劃內(nèi)還是偶然撞見。

Uber那個1萬美元的漏洞，Tobias后來在一次訪談里說，他測試時根本沒想過會拿到錢。"就是好奇改了一下參數(shù)，看到數(shù)據(jù)回來嚇了一跳"。這種無目的的好奇心是安全研究的原始動力，但系統(tǒng)化訓(xùn)練能讓你更快把偶然發(fā)現(xiàn)變成可復(fù)現(xiàn)的能力。

這個實驗就是系統(tǒng)化訓(xùn)練的一小塊拼圖。它不會教你所有東西，但確保你在"302跳轉(zhuǎn)"這個特定場景下，不會重復(fù)Tobias之前無數(shù)人的錯誤。

我提交完實驗報告，把Burp的Proxy History清空，準備下一個。屏幕右下角彈出一條通知：PortSwigger發(fā)布了新的GraphQL漏洞實驗。攻擊面永遠在擴展，而獵人的時間有限。優(yōu)先級判斷和具體技術(shù)同樣重要。

這個IDOR實驗我推薦給所有想入門賞金的人，不是因為技術(shù)難度，是因為它暴露了"知道"和"做到"之間的真實距離。你可以背下所有漏洞定義，但直到親手在302響應(yīng)體里翻出API密鑰，才算真正理解為什么這個漏洞值1萬美元。

下次你在測試中看到302跳轉(zhuǎn)，會記得檢查響應(yīng)體嗎？還是會和大多數(shù)人一樣，直接跟著Location頭走了？