測試前： 先確認測試範圍（確定測試物件，需要dev協助）--再手動驗證-確認，最後確定是否需要優化
【驗證方法】通過修改用於直接指向物件的引數值直接訪問
【影響】可以繞過許可權，直接訪問系統的資源（但這些資源可以是屬於其他使用者的資料庫條目、系統中的檔案等等）
【原因】這是因為應用程式接受使用者提供的輸入並使用它檢索物件，而沒有執行足夠的授權檢查。
確認位置：需要繪製出應用程式中所有使用使用者輸入直接引用物件的位置
改引數：修改用於引用物件的引數的值，並評估是否可以檢索屬於其他使用者的物件或繞過授權。
通過多使用者的資料訪問許可權驗證：
建議用2
個使用者（或相同角色 猜測是否能訪問他人資料）（或不同角色 測試許可權控制）
測試直接物件引用的最佳方法是讓至少兩個（通常更多）使用者覆蓋不同擁有的物件和功能。例如，兩個使用者各自有權訪問不同的物件（如購買資訊、私人訊息等），以及（如果相關）具有不同許可權的使用者（如管理員使用者），以檢視是否存在對應用程式功能的直接引用。
通過擁有多個使用者，測試人員可以嘗試訪問屬於其他使用者的物件，從而在猜測不同物件名稱時節省寶貴的測試時間
已知：2
個使用者資料，例如有2個
policyid
，然後檢查是否可以在未經授權的情況下訪問物件。
已知：2
個使用者username
，修改使用者密碼（不要求當前密碼）
在許多情況下，此步驟將是嚮導或多步驟操作的一部分。在第一步中，應用程式將收到乙個請求，說明要更改哪個使用者的密碼，在下一步中，使用者將提供乙個新密碼（不要求當前密碼）
使用者引數用於直接引用將為其執行密碼更改操作的使用者的物件。
測試方法：
修改user
為非當前登陸的使用者名稱，
檢查是否可以修改另乙個使用者的密碼
測試方法：是否能夠檢索屬於其他使用者的物件（）。
為了測試這種情況，測試人員應該準備乙個當前使用者不應該能夠訪問的引用物件，並嘗試使用它作為檔案引數的值來訪問它。注意：此漏洞通常與目錄
/路徑遍歷漏洞一起被利用（請參閱路徑遍歷測試）
已知選單訪問對應id：
1、2、
3……，
測試方法：假設使用者受到限制，只有訪問選單項1、
2和3的鏈結可用。通過修改
menuitem
引數的值，是否可以繞過授權並訪問其他應用程式功能
參照：
不安全的直接物件引用
一般 開發人員的學習大體路子應該是 開發動態 一般情況下都會涉及到使用者 許可權這些安全層面的東西，如何確保自己的 是乙個相對安全的 呢？是否覺得自己做的 好像沒有什麼漏洞，因為demo啊，docs啊都沒有提及這方面，都是說應該怎麼做，但同時又總有些不放心，隱隱約約覺得怕出問題，只好盲目的以為框架會...
不安全的物件引用 垂直越權
該系統僅允許註冊社工賬號，此賬號許可權極低，無法檢視任何資訊，嘗試通過不安全的物件直接引用漏洞來獲取高許可權賬號。1.首先判斷出，社工與區管理員登入時使用者名稱識別的引數存在什麼不同 經抓包對比測試得知，社工賬戶和區管理員賬戶userinfobean.usertype的引數不同，社工賬戶 useri...
Servlet執行緒的不安全
servlet是j2ee是一部分 也是j2ee規範中處理http請求的部件 為什麼說servlet中線程是不安全的呢？在servlet中對於同乙個servlet物件的多個請求,servlet的service方法將在乙個多執行緒的環境中併發執行,所以,web容器預設採用單例模式多執行緒的方式來處理ht...