IDOR Infinite Money Glitch? | Bug Bounty Hacktivity Explained
三句話摘要
透過 Mozilla、HackerOne、PayPal 三個真實 Bug Bounty 案例，示範 IDOR 漏洞在大型企業中至今仍普遍且高報酬的原因。 --- IDOR 之所以長青不衰，是因為每次功能迭代都可能在新路徑上遺漏存取控制驗證，而 AI 輔助開發進一步加劇了這個問題，使其成為 Bug Bounty 中投入產出比最高的漏洞類型。 IDOR 本質簡單但影響巨大。 攻擊者只需將 API 請求中的唯一識別碼（UID、org ID、account ID）換成其他值，若伺服器未做存取控制驗證即回應，就構成漏洞；正因為操作門檻極低，漏洞卻往往可以讀取私密資料或執行破壞性操作，Bug Bounty 賠付金額相當可觀。
重點整理
重點- 1
IDOR 本質簡單但影響巨大。 攻擊者只需將 API 請求中的唯一識別碼（UID、org ID、account ID）換成其他值，若伺服器未做存取控制驗證即回應，就構成漏洞；正因為操作門檻極低，漏洞卻往往可以讀取私密資料或執行破壞性操作，Bug Bounty 賠付金額相當可觀。
- 2
SSO 整合路徑常成為存取控制盲點。 Mozilla 案例中，原本刪除帳號需要密碼驗證，但 SSO（Google/Facebook/Apple 登入）路徑只需 Email，開發者在整合 SSO 時忘記將刪除端點的驗證邏輯同步更新，造成任何人只要知道他人 Email 即可刪除帳號。
- 3
非標準端點（如 .json 結尾）容易被掃描工具與 AI 工具忽略存取控制審查。 HackerOne 案例中，因為端點格式特殊，推測使用的掃描或 AI 代碼工具未將其視為需要做存取控制的 REST API 端點，導致 organization_id 參數無驗證。
- 4
複雜帳號層級關係是 IDOR 的溫床。 PayPal 的 primary/secondary 帳號結構讓存取控制邏輯變複雜，開發者在處理「一個 secondary 帳號可屬於多個 primary」這個邊緣情境時，遺漏了對 secondary account ID 的擁有權驗證。
- 5
--
實用技巧與重點
乾貨- 漏洞類型：IDOR（Insecure Direct Object Reference）
- 測試方法：將 API 請求中的 UID/org_id/account_id 替換為他人的 ID，觀察伺服器是否回應資料
- IDOR 位置不只在 URL：也存在於 Request Body、JSON key、自訂 Header（如 `X-Auth-Originator`）、Cookie
- Mozilla 案例：
- 端點：刪除帳號 API
- 條件：SSO 登入路徑（Google/Facebook/Apple）只需提供受害者 Email
- 影響：任意刪除他人 Firefox 帳號
- 根因：SSO 整合後，刪除端點未同步加上 token 驗證
- HackerOne 案例：
- 端點：`/reports.json`（含 organization_id 參數）
- 影響：讀取任意組織的私人漏洞報告（含未公開的 CVE 資訊）
- 根因：`.json` 非標準端點被程式碼掃描/AI 工具視為靜態資源，跳過存取控制審查
- PayPal 案例（2019年）：
- 端點：管理 secondary account 的 API
- 操作：將已知的他人 secondary account ID 填入請求，把自己加入該帳號
- 影響：加入後可存取並轉移該帳號資金
- 根因：secondary 帳號可隸屬多個 primary 的邏輯邊緣案例未驗證擁有權
- 趨勢：2019 年至 2025 年 IDOR 持續高頻出現；AI 輔助開發使 IDOR 增加而非減少
- 引用人物：Douglas Day、Svink（自稱 IDOR Dominator）
- 平台提及：HackerOne（Bug Bounty 平台）
- --
結論
結論“IDOR 之所以長青不衰，是因為每次功能迭代都可能在新路徑上遺漏存取控制驗證，而 AI 輔助開發進一步加劇了這個問題，使其成為 Bug Bounty 中投入產出比最高的漏洞類型。”
完整解析
詳細IDOR（Insecure Direct Object Reference，不安全的直接物件參照）是 Web 安全中最古老也最持久的漏洞類型之一。其原理極為直接：當 API 端點接受用戶提供的資源識別碼（如用戶 ID、報告 ID、帳號 ID），並在未驗證請求者是否有權存取該資源的情況下直接回傳或操作資料，即構成 IDOR。影片作者指出，儘管業界普遍認為 AI 的導入應該提升程式碼安全性，但實際觀察顯示，AI 輔助開發反而讓 IDOR 變得更加普遍，因為 AI 工具在生成或審查代碼時，往往忽略邊緣情境下的存取控制驗證。
第一個案例來自 Mozilla（Firefox 帳號系統）。Mozilla 的帳號刪除端點原本需要用戶提供自己的 Email 及密碼，這使得 IDOR 難以利用——即使能猜到他人 UID，也還需要對方密碼。然而，當 Mozilla 後來整合 SSO（Google、Facebook、Apple 登入）時，SSO 路徑的刪除流程只需要提供 Email，不再要求密碼。開發者在實作 SSO 功能時，沒有對刪除帳號的端點補上相應的驗證邏輯，導致任何知道他人 Email 的人都能直接刪除其 Firefox 帳號。作者推測這是功能迭代時的遺漏：原始刪除功能設計時未考慮無密碼登入情境，SSO 後來接入時開發者低估了存取控制的必要性。
第二個案例出自 HackerOne 自身的平台。HackerOne 上的漏洞報告分為公開與私人兩種，私人報告通常包含尚未公開的漏洞細節，極為敏感。研究者發現，某個以 `.json` 結尾的 API 端點在回傳報告資料時，接受了一個 `organization_id` 參數，只需更換該參數的值，即可讀取任意組織的所有私人報告。作者認為根因在於：許多企業使用的程式碼審查工具或 AI 工具，看到 `.json` 結尾時會將其歸類為靜態資源而非需要存取控制的 REST API 端點，因此略過了安全審查，讓這個參數在缺乏驗證的狀態下被部署上線。
第三個案例來自 PayPal（2019 年）。PayPal 允許用戶在主帳號（primary account）下建立子帳號（secondary account），且一個子帳號可以隸屬於多個主帳號。負責管理子帳號的 API 端點存在一個 IDOR：攻擊者只需將請求中的 secondary account ID 替換成他人的子帳號 ID，即可將自己加入該帳號，進而獲得存取甚至轉移帳號資金的權限。這個案例的根因是複雜的帳號層級關係讓存取控制邏輯難以全面覆蓋，開發者在處理「一個子帳號可屬於多個主帳號」這個邏輯分支時，遺漏了對請求者是否為子帳號現有擁有者的驗證。
三個案例共同印證了作者的核心論點：IDOR 從 2019 年到 2025 年從未消失，不論是 Mozilla 這樣的開源軟體巨頭、HackerOne 這類專精安全的平台，或是 PayPal 這樣的金融服務公司，都仍然持續出現高影響力的 IDOR 漏洞。其共同根因幾乎都是功能迭代時的存取控制遺漏，而非從一開始就設計錯誤。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
