简介
失效的直接对象引用 (Insecure Direct Object References, IDOR) 是一种访问控制漏洞，当应用程序使用用户提供的输入直接访问对象时，就会产生此类漏洞。如果应用程序没有充分验证请求该对象的用户是否拥有访问权限，攻击者就可以通过篡改引用（例如 URL 中的数据库 ID、文件名或用户 ID）来访问其他用户的敏感数据。
需要明确的是，引用本身并不是漏洞。真正的漏洞在于：在未检查当前用户是否被允许访问该对象的情况下，盲目信任了该引用。
在本实验中，你将扮演一名安全测试人员，对一个本地 Web 应用程序 API 进行评估。你将首先以普通用户身份进行身份验证，分析应用程序如何引用你的用户资料，然后利用 IDOR 漏洞访问其他用户（包括管理员）的私有数据。
以普通用户身份进行身份验证
在此步骤中，你将与运行在本地机器 5000 端口上的 Web API 进行交互。为了开始测试应用程序的漏洞，你首先需要以普通用户身份进行身份验证，以获取有效的会话令牌。
我们已为你提供了一名名为 Alice 的普通用户凭据。她的用户名为 alice，密码为 password123。
你将使用 curl 命令行工具向登录端点发送 HTTP POST 请求。curl 是一个功能强大的工具，用于在服务器之间传输数据。
在终端中运行以下命令进行登录：
curl -X POST http://localhost:5000/api/login \
-H "Content-Type: application/json" \
-d '{"username": "alice", "password": "password123"}'
让我们解析一下该命令：
-X POST指定我们正在发送一个 POST 请求，这通常用于提交登录凭据等数据。-H "Content-Type: application/json"告诉服务器我们发送的数据格式为 JSON。-d '...'包含了带有用户名和密码的实际 JSON 数据负载。
如果凭据正确，你应该会看到类似以下的输出：
{"token": "Bearer alice_token", "user_id": "1001"}
请记下 token 和 user_id。该令牌 (Bearer alice_token) 充当你的数字身份证。在后续请求中，你需要包含它以证明你已通过身份验证。user_id (1001) 是你在应用程序数据库中的唯一标识符。
分析对象引用 (URL/API)
现在你已以 Alice 的身份通过了身份验证，可以访问她的用户资料了。在许多 Web 应用程序中，用户资料是通过 API 端点访问的，该端点需要你的身份验证令牌以及对特定对象（在本例中为用户资料）的引用。
你将再次使用 curl，但这次你将向 /api/profile 端点发送 GET 请求。你必须在 HTTP 请求头中包含身份验证令牌，并在 URL 中指定你的 user_id。
这正是真实 API 中常见的模式：令牌证明会话存在，而参数则用于选择要获取的对象。安全的应用程序必须通过授权检查将这两者结合起来。
执行以下命令查看 Alice 的资料：
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1001"
在该命令中：
-H "Authorization: Bearer alice_token"将你的数字身份证传递给服务器。?user_id=1001是附加在 URL 后的查询参数。这就是直接对象引用。它明确告诉服务器要获取哪个数据库记录。
你应该会收到包含 Alice 资料信息的 JSON 响应：
{"name": "Alice", "role": "user", "email": "alice@example.com", "secret": "alice_secret_123"}
请注意，应用程序是如何依赖 URL 中的 user_id=1001 参数来决定返回哪些数据的。一个安全的应用程序会验证与 Bearer alice_token 关联的用户是否确实被允许查看 user_id=1001 的数据。如果应用程序未能执行此授权检查，它就存在 IDOR 漏洞。
操纵用户 ID
在此步骤中，你将测试应用程序是否正确执行了访问控制。你目前是以 Alice 的身份登录的，但如果你请求服务器获取其他用户的数据会发生什么呢？
这是授权的核心问题。「我是否已登录？」和「我是否被允许读取此对象？」是不同的检查，混淆这两者直接导致了 IDOR。
假设还有另一个名为 Bob 的普通用户，他的用户 ID 是 1002。如果应用程序存在 IDOR 漏洞，它将盲目信任 URL 中的 user_id 参数，而不会检查 Alice 是否有权查看 Bob 的资料。
将上一条命令中的 user_id 参数从 1001 修改为 1002。运行以下命令：
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=1002"
观察服务器返回的输出：
{"name": "Bob", "role": "user", "email": "bob@example.com", "secret": "bob_secret_456"}
你已经成功获取了 Bob 的私有信息，包括他的电子邮件和密钥，而此时你仍然是以 Alice 的身份登录的！
这证实了失效的直接对象引用 (IDOR) 漏洞的存在。服务器检查了你是否已登录（通过验证令牌），但未能检查你是否有权访问你所请求的特定对象（Bob 的资料）。
访问未经授权的数据
在确认了 IDOR 漏洞后，你现在可以升级攻击以获取高度敏感的信息。在许多系统中，管理员用户的 ID 是可预测的，例如 1、0 或 9999。
对于此应用程序，管理员的用户 ID 是 9999。通过利用相同的 IDOR 漏洞，你可以尝试提取包含秘密标志 (secret flag) 的管理员资料。
为了记录你的发现，你将把 curl 命令的输出重定向到当前工作目录 (~/project) 下一个名为 flag.txt 的文件中。
运行以下命令获取管理员资料并保存：
curl -H "Authorization: Bearer alice_token" \
"http://localhost:5000/api/profile?user_id=9999" > ~/project/flag.txt
> 符号会将原本应打印到屏幕上的输出重定向到指定文件中。
要验证你是否已成功捕获管理员数据，请使用 cat 命令读取文件内容：
cat ~/project/flag.txt
你应该能看到管理员的资料数据，其中包括秘密标志：
{"name": "Admin", "role": "admin", "email": "admin@example.com", "secret": "FLAG{IDOR_VULN_EXPLOITED}"}
恭喜！你已成功利用 IDOR 漏洞绕过访问控制并获取了敏感的管理员数据。
总结
在本实验中，你探索了失效的直接对象引用 (IDOR) 的机制，这是一种关键的访问控制缺陷。你首先以普通用户身份进行了身份验证，并分析了应用程序如何通过 URL 参数引用用户数据。通过操纵这些参数，你成功绕过了授权检查，查看了其他用户的私有资料。最后，你升级了攻击以提取敏感的管理员数据。
本次练习强调了在服务器端实施稳健授权检查的重要性。应用程序绝不能仅仅依赖用户提供的输入来授予对对象的访问权限；它们必须始终验证已通过身份验证的用户是否拥有访问所请求资源的明确权利。
