How to hunt for A01 : 2021- Broken Access Control

6 min readOct 6, 2021

It is important for every application engineer to understand the difference between authentication and authorization and how to enforce both. Web applications contain many roles used to handle different operations.

What are Access Control Vulnerabilities?

Access controls are designed to prevent users from acting outside their intended permissions, when vulnerabilities exist in these controls, or there are no controls users can act outside of their intended permissions. This may allow attackers to steal information from other users, modify data and perform actions as other users.

There are different ways to hunt for Broken Access Control Vulnerabilities.

For example as we discussed in our OWASP TOP 2021

-Allowing any authenticated user to be able to access the administrative page of the application.

-Missing Functional Level Access Control: Allow users to perform the function that should be restricted.

-Privilege Escalation or privileged entry to sources that is restricted to the users.

-Distributed Denial of Service.

-Bypassing access control checks by modifying the URL (parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool modifying API requests.

-Allowing to view or edit someone else’s account, by providing its unique identifier (insecure direct object references-IDOR)

-Accessing API with missing access controls for POST, PUT and DELETE methods.

-CORS misconfiguration allows an attacker to API access from unauthorized/untrusted origins.

-Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a common user.

-Bypassing access control checks by modifying the URL

-Elevation of privileges. Acting as a user without being logged in or acting as an admin when logged in as a user.

Etc.. were the examples of broken access control vulnerabilities.

Let’s Start to hunt for IDOR:

Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly.

Testing for IDOR/Broken object level authorization:

Difficulty: Easy

Tips: Don’t blindly test for changing numbers till you get PII, tools can do this for you

Finding IDOR Attack Vectors Ideas:[Ask Questions Yourself]

-What do they use for authorization?(JWT, API Keys, cookies, tokens) Tip: Find this out by replacing high privilege authorization with lower privilege authorization and seeing what the server responds with

-Understand how they use ID’s, hashes, and their API. Do this by looking at the API Documentations if they have one.

Consider a website that uses the following URL to access the customer account page, by retrieving information from the back-end database:

https://insecure-website.com/customer_account?customer_number=132355

Try to change the customer_number to any other until you receive 200.

Every time you see a new API endpoint that receives an object ID from the client, ask yourself the following questions:

*Does the ID belong to a private resource? (e.g /api/user/123/news vs /api/user/123/transaction)
*What are the IDs that belong to me?
*What are the different possible roles in the API?(For example — user, driver, supervisor, manager)

The value of a parameter is used directly to retrieve a database record.

https://insecure-website.com/somepage?invoice=12345

The value of a parameter is used directly to perform an operation in the system

https://insecure-website.com/changepassword?user=someuser

The value of a parameter is used directly to retrieve a file system resource

https://insecure-website.com/showImage?img=img00011

The value of a parameter is used directly to access application functionality

https://insecure-website.com/accessPage?menuitem=12

Hackerone Report Example:

IDOR to view User Order Information

Application & Version:

https://store.redacted.com/order/1003793?confirmed=true

Steps To Reproduce:

1.Login to your account

2.Visit the above endpoint

3.You can iterate through the order ID to view other users’ details.

Change the 1003793 to 1003725.

Steps involved in execution of IDOR attack:

Burp Suite Tool is widely used by attackers to execute such type of Attacks. Following are the steps being followed:

1.Capture the Request: First of all, an attacker will decide a target website to which he wants to execute an IDOR attack. Then the website is added to the scope and spider the website to get all the URLs with specific parameters in it.

2.Filter the parameters Request: After the first step, we will filter our captured request with the parameter filters. An attacker will only choose that parameter or Injection points where they can execute the attacks.

3.Forward request to Repeater: Now, if an attacker will find some of the injection point where they can execute IDOR, they will forward the request to the repeater. The vulnerable URL might look something like this: www.xyz.com/myaccount/uid=19. Here the “UID” seems to be vulnerable.

4.Tampering of Parameters: Now as the attacker has the vulnerable injection point, they will now try to execute the IDOR attack with the help of Social engineering or the pattern as written in injection point. Example: an attacker may change uid from 19 to 20 which will open account of another user who has been assigned id number 20.