BugBountyHunter

Learning about Broken Access Control

Broken Access Control is when you are able to access or modify information you should not have access to. This could be related to being unauthenticated, or accessing content that your user role should have have access to. IDOR (Insecure Direct Object Reference) is considered a broken access control vulnerability as you are able to access/modify information you should not be allowed to, typically via changing an integer value.

Below are some more examples of broken access control vulnerabilities as well as information on how you can test for them.

• You can access /admin/upload as an authenticated user (non admin)

  If you are authenticated on the web application and you can access admin only content, such as sensitive endpoints, API queries, GraphQL queries when you are only authenticated as a normal user then you have a clear broken access control. But!, don't just think about just admin functionality. This can apply to all types of user roles!

  If the website you are testing offers different types of user roles (guest, user, owner, employee, staff, admin) then you will want to try every endpoint from various angles. How many endpoints can a normal user access, and can employee access anything staff can? The bigger the web application with more roles/user permissions, the more you will have to play with. (This is why it's recommended to focus on large scope programs if doing bug bounties full time).

  When testing differnet roles always consider, what's the impact of me accessing this? Sometimes it's intended to be able to view certain endpoints but the functionality may not exist for it (yet).

• You can access /api/users unauthenticated

  Imagine you are logged into a website which is members only. When browsing a list of members, an authenticated request is sent to api/users and shown to the user. However, if you can access this endpoint unauthenticated then you have another broken access control as you are able to access content you should not have access to. When looking for these types of issues it is worth noting down endpoints which should require authentication and then browsing them unauthenticated. You could even automate this in Burp Intruder.

  Again when testing for this, always consider: what's the impact of me accessing this? Sometimes it's intended to be able to view certain endpoints unauthenticated! Always assess what you can access.

• You can access /api/user/123 as another user (user id 1337)

  This is what would be considered an IDOR vulnerability, but if you are able to access other users sensitive information from changing a value in the request (typically integer), then it is considered a broken access control issue. You are again accessing information you should not have access to! This will also apply to being able to modify information you should not have access to. Check out our IDOR guide to learn more.

When looking for broken access control it will help if you have knowledge around the web application you are testing. What roles are available, what functionality is available, and what's the intended use? For example they may restrict new users from uploading videos until they have been a member for a certain amount of days, but if you were able to bypass this and upload new videos anyway then you would have yourself a valid issue.

Spend time learnin your target and writing notes and you will begin discovering broken access control vulnerabilities. The bigger the scope, the more features and the more user permissions available, the more there will be for you to dive into.