- The Guide to Finding and Reporting Web Vulnerabilities
- About the Author
- About the Tech Reviewer
- Foreword
- Introduction
- Who This Book Is For
- What Is In This Book
- Happy Hacking!
- 1 Picking a Bug Bounty Program
- 2 Sustaining Your Success
- 3 How the Internet Works
- 4 Environmental Setup and Traffic Interception
- 5 Web Hacking Reconnaissance
- 6 Cross-Site Scripting
- 7 Open Redirects
- 8 Clickjacking
- 9 Cross-Site Request Forgery
- 10 Insecure Direct Object References
- 11 SQL Injection
- 12 Race Conditions
- 13 Server-Side Request Forgery
- 14 Insecure Deserialization
- 15 XML External Entity
- 16 Template Injection
- 17 Application Logic Errors and Broken Access Control
- 18 Remote Code Execution
- 19 Same-Origin Policy Vulnerabilities
- 20 Single-Sign-On Security Issues
- 21 Information Disclosure
- 22 Conducting Code Reviews
- 23 Hacking Android Apps
- 24 API Hacking
- 25 Automatic Vulnerability Discovery Using Fuzzers
Hunting for IDORs
Let’s hunt for some IDORs! The best way to discover IDORs is through a source code review that checks if all direct object references are protected by access control. We’ll talk about how to conduct source code reviews in Chapter 22 . But if you cannot access the application’s source code, here’s a simple and effective way to test for IDORs.
让我们寻找一些 IDORs!发现 IDOR 的最佳方法是通过源代码审查,检查是否所有直接对象引用都受到访问控制的保护。我们将在第 22 章中讨论如何进行源代码审查。但是,如果您无法访问应用程序的源代码,这里有一种简单而有效的测试 IDOR 的方法。
Step 1: Create Two Accounts
First, create two different accounts on the target website. If users can have different permissions on the site, create two accounts for each permission level. For example, create two admin accounts, two regular user accounts, two group member accounts, and two non-group-member accounts. This will help you test for access control issues among similar user accounts, as well as across users with different privileges.
首先,在目标网站创建两个不同的账户。如果用户可以在网站上获得不同的权限,请为每个权限级别创建两个帐户。例如,创建两个管理员帐户、两个普通用户帐户、两个组成员帐户和两个非组成员帐户。这将帮助您测试类似用户帐户之间以及具有不同特权的用户之间的访问控制问题。
Continuing the previous example, you could create two accounts on example.com : user 1235 and user 1236 . One of the accounts would serve as your attacker account, used to carry out the IDOR attacks. The other would be the victim account used to observe the effects of the attack. The message pages for the two users would have the following URLS:
在之前的例子中,你可以在 example.com 上创建两个帐户:用户 1235 和用户 1236。其中一个帐户将充当攻击者帐户,用于进行 IDOR 攻击。另一个帐户将被用作受害者帐户,以观察攻击的影响。这两个用户的消息页面将具有以下 URLS:
- https://example.com/messages?user_id=1235 (Attacker)
- https://example.com/messages?user_id=1236 (Victim)
If the application doesn’t allow you to create so many accounts, you could reach out to the company and ask for more accounts. Companies will often grant you extra accounts if you explain that you’re participating in their bug bounty program. Also, if the application has paid memberships, ask the company for a premium account or pay for one yourself. Quite often, paying for these memberships is worth it, because you gain access to new features to test.
如果应用程序不允许您创建很多帐户,您可以联系该公司并要求更多帐户。如果您解释说您正在参与他们的漏洞赏金计划,公司通常会授予您额外的帐户。另外,如果该应用程序有付费会员资格,可以要求公司提供高级帐户或自己支付。很多时候,支付这些会员资格是值得的,因为您可以获得新的测试功能的访问权限。
In addition to testing with two accounts, you should also repeat the testing procedure without signing in. See if you can use an unauthenticated session to access the information or functionalities made available to legitimate users.
除了使用两个账户进行测试外,您还应该在未登录的情况下重复测试程序。查看您是否可以使用未经验证的会话来访问提供给合法用户的信息或功能。
Step 2: Discover Features
Next, try to discover as many application features as possible. Use the highest-privileged account you own and go through the application, looking for application features to test.
接下来,尝试尽可能多地发现应用程序的功能。使用您拥有的最高权限帐户,浏览应用程序,寻找要测试的应用程序功能。
Pay special attention to functionalities that return user information or modify user data. Note them for future reference. Here are some features that might have IDORs on example.com :
特别注意返回用户信息或修改用户数据的功能。将它们记录下来以备将来参考。以下是一些在 example.com 上可能存在 IDOR 的功能特性:
- This endpoint lets you read user messages:
https://example.com/messages?user_id=1236
- This one lets you read user files:
https://example.com/uploads?file=user1236-01.jpeg
- This endpoint deletes user messages:
POST /delete_message
(POST request body)
message_id=user1236-0111
- This one is for accessing group files:
https://example.com/group_files?group=group3
- This one deletes a group:
POST /delete_group
(POST request body)
group=group3
Step 3: Capture Requests
Browse through each application feature you mapped in the preceding step and capture all the requests going from your web client to the server. Inspect each request carefully and find the parameters that contain numbers, usernames, or IDs. Remember that you can trigger IDORs from different locations within a request, like URL parameters, form fields, filepaths, headers, and cookies.
浏览您在先前步骤中映射的每个应用程序功能,并捕获所有从您的 Web 客户端发送到服务器的请求。仔细检查每个请求,找到包含数字、用户名或 ID 的参数。请记住,您可以从请求的不同位置触发 IDOR,例如 URL 参数、表单字段、文件路径、标头和 cookie。
To make testing more efficient, use two browsers, and log into a different account in each. Then manipulate the requests coming from one browser to see if the change is immediately reflected on the other account. For example, let’s say you create two accounts, 1235 and 1236 . Log into 1235 in Firefox and 1236 in Chrome.
为了使测试更有效率,使用两个浏览器,在每个浏览器中登录不同的账户。然后通过一个浏览器来操纵请求,以查看在另一个账户上是否能立即看到更改。例如,假设您创建了两个账户,1235 和 1236。在 Firefox 中登录到 1235,在 Chrome 中登录到 1236。
Use Burp to modify the traffic coming from Firefox. Turn on Intercept in the Proxy tab and edit requests in the proxy text window ( Figure 10-1 ). Check if your attack has succeeded by observing the changes reflected on the victim account in Chrome.
使用 Burp 修改来自 Firefox 的流量。在代理选项卡中启用拦截,并在代理文本窗口(图 10-1)中编辑请求。通过观察 Chrome 中受害者账户反映的更改来检查攻击是否成功。
Also, note that APIs like Representational State Transfer (REST) and GraphQL are often found to be vulnerable to IDOR too. We will talk more about hacking APIs in Chapter 24 . Be on the lookout for these endpoints. You can use the recon techniques from Chapter 5 to discover additional endpoints. Then follow this testing methodology to switch out IDs found in those endpoints as well.
还要注意,Representational State Transfer(REST)和 GraphQL 等 API 通常也容易受到 IDOR 攻击。在第 24 章中,我们将详细讨论如何攻击 API。请注意这些端点。您可以使用第 5 章的侦察技术发现其他端点,然后按照此测试方法来替换这些端点中发现的 ID。
Step 4: Change the IDs
Finally, switch the IDs in the sensitive requests and check if the information returned also changes. See if you can access the victim account’s information by using the attacker account. And check if you can modify the second user’s account from the first.
最后,交换敏感请求中的 ID,并检查返回的信息是否也发生了变化。尝试使用攻击者帐户访问受害者帐户的信息。并检查是否可以从第一个用户修改第二个用户的帐户信息。
For example, in this setup, you can try to access the functionalities that user 1236 has access to via your Firefox browser:
例如,在这个设置中,您可以通过 Firefox 浏览器尝试访问用户 1236 访问权限中的功能:
- This endpoint lets you read user messages:
https://example.com/messages?user_id=1236
- This one lets you read user files:
https://example.com/uploads?file=user1236-01.jpeg
- This endpoint deletes user messages:
POST /delete_message
(POST request body)
message_id=user1236-0111
- This one is for accessing group files:
https://example.com/group_files?group=group3
- This endpoint deletes a group:
POST /delete_group
(POST request body)
group=group3
If any of these requests succeed in accessing or modifying user 1236 ’s information, you’ve found an IDOR vulnerability.
如果任何一项请求成功访问或修改了用户 1236 的信息,那么你就发现了一个 IDOR 漏洞。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论