测试前： 先确认测试范围（确定测试对象，需要dev协助）--再手动验证-确认，最后确定是否需要优化

定义Insecure Direct Object References (IDOR)  不安全的直接对象引用

【验证方法】通过修改用于直接指向对象的参数值直接访问

【影响】可以绕过权限，直接访问系统的资源（但这些资源可以是属于其他用户的数据库条目、系统中的文件等等）

【原因】这是因为应用程序接受用户提供的输入并使用它检索对象，而没有执行足够的授权检查。

How to test

确认位置：需要绘制出应用程序中所有使用用户输入直接引用对象的位置

改参数：修改用于引用对象的参数的值，并评估是否可以检索属于其他用户的对象或绕过授权。

通过多用户的数据访问权限验证：

建议用2个用户（或相同角色 猜测是否能访问他人数据）（或不同角色 测试权限控制）

测试直接对象引用的最佳方法是让至少两个（通常更多）用户覆盖不同拥有的对象和功能。例如，两个用户各自有权访问不同的对象（如购买信息、私人消息等），以及（如果相关）具有不同权限的用户（如管理员用户），以查看是否存在对应用程序功能的直接引用。

通过拥有多个用户，测试人员可以尝试访问属于其他用户的对象，从而在猜测不同对象名称时节省宝贵的测试时间

一，参数的值直接用于检索数据库记录 

已知：2个用户数据，例如有2个policyid，然后检查是否可以在未经授权的情况下访问对象。

二，参数值直接用于在系统中执行操作

已知：2个用户username，修改用户密码（不要求当前密码）

在许多情况下，此步骤将是向导或多步骤操作的一部分。在第一步中，应用程序将收到一个请求，说明要更改哪个用户的密码，在下一步中，用户将提供一个新密码（不要求当前密码）

用户参数用于直接引用将为其执行密码更改操作的用户的对象。

测试方法：

http://foo.bar/changepassword?user=someuser

修改user 为非当前登陆的用户名，检查是否可以修改另一个用户的密码

三，参数的值直接用于检索文件系统资源

http://foo.bar/showImage?img=img00011

测试方法：是否能够检索属于其他用户的对象（）。

为了测试这种情况，测试人员应该准备一个当前用户不应该能够访问的引用对象，并尝试使用它作为文件参数的值来访问它。注意：此漏洞通常与目录/路径遍历漏洞一起被利用（请参阅路径遍历测试）

四，参数的值直接用于访问应用程序功能

http://foo.bar/accessPage?menuitem=12

已知菜单访问对应id：1、2、3……，

测试方法：假设用户受到限制，只有访问菜单项1、2和3的链接可用。通过修改menuitem参数的值，是否可以绕过授权并访问其他应用程序功能

参照：

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References