不安全的直接物件參照（Insecure Direct Object References，IDOR）發生在攻擊者能存取或修改本不該存取的物件參照——檔案、資料庫紀錄、帳號等。經典例子：www.example.com/user?id=1 顯示自己 profile，把 id 改成 2 就能看到別人 profile，這就是 IDOR。

簡單型 IDOR#

最容易的 IDOR：id 是自動遞增整數。直接 +1 / -1 試試，看能不能撈到別人的資料。

工具流程：

  1. 用 Burp Suite 攔下請求
  2. 把請求送到 Intruder
  3. 對 id 設 numerical payload，自動列舉
  4. 觀察 HTTP 狀態碼 與 回應長度
    • 全部 403 + 同樣長度 → 沒有漏洞
    • 200 + 不同長度 → 高機率拿到別人資料

複雜型 IDOR#

當 id 不在明顯位置時，找漏洞的成本提高：

  • 藏在 POST body
  • 名字模糊（ref、user、column）
  • 用 UUID（Universal Unique Identifier）——36 字元、無規律——猜不出來

對付 UUID#

無法暴力列舉時：

  • 建立兩個帳號 A、B：用 A 建立物件，再以 B 嘗試使用 A 的 UUID 存取
  • 找洩漏點：HTTP 回應、JSON、HTML 原始碼、邀請流程、搜尋結果都可能洩漏 UUID
  • 即便沒洩漏，若該操作清楚違反權限模型，部分計畫仍會接受——但你需要解釋影響

案例 1：Binary.com Privilege Escalation#

漏洞描述#

研究者 Mahmoud Gamal 在 binary.com 發現 /cashier 頁面以 iFrame 載入 cashier.binary.com，URL 參數中夾帶 pin、password、secret。pin 是遞增整數：

  • 用帳號 A 訪問 /cashier，記下 pin
  • 用帳號 B 把該 pin 套到自己的 iFrame
  • 成功操作帳號 A 的資金（包括提款）

Takeaways#

  • 註冊兩個帳號並排測試是 IDOR 的標準起手式
  • iFrame 內的 URL 與參數不會出現在瀏覽器網址列——務必用 Burp 等代理工具觀察底層請求
  • Burp 外掛 Autorize ↗、Authmatrix ↗ 可自動化權限切換測試

案例 2：Moneybird App Creation#

漏洞描述#

Moneybird 用 administration_id 區分企業帳號。id 雖長且亂數，但使用者被邀請進入企業時 URL 就會洩漏 ID：

https://moneybird.com/ABCDEFGHIJKLMNOP/

作者用兩個帳號測試：

  1. 帳號 A 建立企業並邀請帳號 B
  2. 帳號 B 取得 A 的 administration_id
  3. 帳號 B 自己另建一個企業，並建立 App
  4. 在建立 App 的 POST 請求中，用 Burp 把 administration_id 改成 A 的 ID
  5. 結果：帳號 B 在帳號 A 的企業上建出一個擁有所有權限的 App

帳號 B 從此繞過原先「有限權限」的設計。

Takeaways#

  • 留意名稱含 id 的參數，特別是值為純數字的
  • 即便 ID 不可猜，先確認站內是否在某處洩漏

案例 3：Twitter Mopub API Token Theft#

漏洞描述#

Akhil Reni 找到 Twitter Mopub 平台的 POST 端點未驗證權限，回應中洩漏 api_key 與 build_secret：

{
  "organization": {
    "id": "5460d2394b793294df01104a",
    "api_key": "8590313c7382375063c2fe279a4487a98387767a",
    "build_secret": "5ef0323f62d71c475611a635ea09a3132f037557d801503573b643ef8ad82054",
    "mopub_id": "33525"
  }
}

organization_id 是 24 位字串看似不可猜，但他用 Google Dork：

site:http://crashes.to/s/

從公開分享的 Crashlytics URL 反查到大量 organization_id。

後續才發現 build_secret 不只是 secret——它出現在這個 URL：

https://app.mopub.com/complete/htsdk/?code=<BUILDSECRET>&next=%2d

該 URL 會以該 secret 自動登入對應帳號——等同任意帳號接管。

Takeaways#

  • 找到 IDOR 後徹底評估 secret 用途——同一個值在不同端點可能有不同用法
  • 如果只報「資料洩漏」，可能拿到較少獎金；補完「可導致帳號接管」就能拉高賞金

案例 4：ACME Customer Information Disclosure#

  • 難度：高
  • URL：https://www.acme.com/customer_summary?customer_id=abeZMloJyUovapiXqrHyi0DshH
  • 回報日期：2017-02-20
  • 獎金：$3,000

漏洞描述#

私有計畫，公司化名為 ACME。作者建立兩個帳號（管理員 + 無權限），發現無權限帳號也能用 customer_id 存取客戶詳情。但因 customer_id 不可猜，初次回報被計畫方標為 informative（無獎金）。

作者沒放棄，繼續找洩漏點。在另一個只有「搜尋訂單」權限的端點裡，回應 JSON 中包含：

{
  "customer_info": {
    "customer_no": "00006001",
    "customer_name": "pete test",
    "customer_id": "abeZMloJyUovapiXqHyi0DshH",
    "email": "test@gmail.com"
  }
}

這個 customer_id 正是先前用來抓客戶資訊的同一個 ID——洩漏點找到，重新提交報告獲得獎金。

Takeaways#

  • 報告被打回不要灰心——找洩漏點再回頭
  • 多端點的 JSON 回應交叉比對，常能找到「xxx_id 在 A 處洩漏，在 B 處被信任」的組合

章末總結#

  • IDOR 三條等級：
    • 簡單：可猜的整數 ID
    • 中等：藏在 POST body 或非顯眼參數
    • 困難：UUID／隨機字串——需找洩漏點
  • 工具：Burp Suite、Burp Intruder、Autorize、Authmatrix
  • 找洩漏點：HTML 原始碼、JSON 回應、URL、邀請流程、Google Dork
  • 報告 IDOR 時務必說明攻擊鏈與最終影響——「帳號接管」遠比「資料洩漏」獎金高
Backward 競態條件 OAuth 漏洞 Forward