那些我們一直想進去的網站：認識 IDOR 不安全直接物件參照
從童年 Flash 小遊戲的漏洞記憶出發，認識 IDOR 如何因伺服器缺少權限檢查，讓使用者只改變網址或 API 參數就讀取不該存取的資料。
記得以前國中電腦課，史萊姆好玩遊戲區一直是我們最常造訪的網站，不像 CS 需要下載，隨開隨玩，別跟我說你沒玩過！
直到有一天我發現，在遊戲裡面，其實按下右鍵，忘記選擇什麼，就可以立馬破關，瞬間消失對遊戲的熱忱 XD。
那時有很多網頁小遊戲都是 Adobe Flash 技術製作的（時代的眼淚），畫面一幀一幀呈現；快速播放等於直接跳到下一關，或突然發現什麼 bug 之類的。那種發現漏洞或找到規則外東西的感覺，其實蠻吸引我的，畢竟我就是不喜歡被規則束縛（？
今天介紹的主題是 IDOR
Insecure Direct Object Reference，中文稱為「不安全直接物件參照」。當初學到時直接看不懂是什麼意思，我們直接來看範例。
假設我們以客人的身份登入一個網頁，網址後面帶著 guest 這個值。如果直接把 guest 改成 admin，結果瞬間變成管理員，這就是不安全直接物件參照，也就是 IDOR。
字面上來說，user: guest 這個物件被直接用不安全的方式參照。舉一反三，也可能像這樣：
- userId=1 改成 userId=2，看到另一位使用者的資料。
- couponId=1 改成 couponId=2，看到另一組優惠券。
問題出在哪裡？
關鍵問題是伺服器端沒有檢查該使用者是否有權限存取這個物件，直接相信用戶端帶過來的資料。這種情況也可能發生在 API request body 裡，不只是在網址列後面。
如何避免 IDOR
後端開發可以遵循「對前端零信任」原則，尤其是涉及權限的操作。每次收到讀取或修改請求，都應由伺服器根據目前登入的身分驗證該使用者是否有權存取指定物件，而不能只依賴用戶端傳來的 ID 或角色值。