當我在請求某一API接口時。發現缺少訪問控制策略（已損壞的訪問控制
策略），這導致我可以未經用戶的允許，編輯或刪除他們的工作經驗和教育細節
先決條件
什么時IDOR？
不安全的直接對象引用（Insecure direct object references，IDOR）是一類訪問控制漏洞，當應用程序使用用戶提供的輸入直接訪問對象時，就會出現該問題。
最近3天我都在測試一個目標站點，發現了一些xss和突破速率限制（Rate limiting）漏洞。我已不再滿足於這些漏洞，所以我開始進一步的挖掘。經過一小時的查找，我的目光停留在一API請求的響應上：
可以明顯的看到這段響應包含了一個‘id’參數（“id”:2150），這引起了我的注意。
該響應產生的緣由是我在目標站點的個人資料中添加了工作經歷，最初的請求為：
我立刻對該位置進行fuzz。我嘗試在請求包的JSON中添加一些參數來創建另一用戶的工作經驗，然而什么也沒發生。
當我准備放棄時，突然想起檢測一下工作經驗的刪除功能。於是我刪除工作經驗並抓取請求：
你應該也在這URL上發現了那個有趣的參數，刪除的URL為：https://www.target.com/api/user-firm/2150
數字2150再次引起了我的主意，我們再看看該請求的響應：
響應的狀態碼為204 No Content，意味着工作經驗被成功刪除並且這位置上已經沒有內容了
現在我按照上面的步驟創建了另一個用戶並且添加工作經驗，該請求為：
響應中的一些字段喚醒了我之前的想法
這里"id"=2151，是我之前賬戶創建工作經驗id的下一位數字，這使我知道id是有規律變化的
我立馬在第一個賬戶中創建一個新的工作經驗，現在的想法是驗證IDOR漏洞
我嘗試使用第一個賬戶通過修改請求包來刪除第二個賬戶的工作經驗
第一個賬戶的刪除請求：
將2150改成2151，並發送請求：
成功！
之后我使用同樣的方法嘗試添加教育細節，幸運的是我再次成功了
提示
- 必須使用參數查看API接口的響應
- 如果API中傳遞了一些數字，那么您必須嘗試使接口fuzz並尋找IDOR。
謝謝您到目前為止的閱讀。 希望你學到了一些東西。
原文地址
https://medium.com/@abhiunix/idor-on-api-endpoints-e08c740e87a2