- Weekly Bug Bounty Content
- Posts
- Broken Access Control (BAC): Understanding BAC vulnerabilities
Broken Access Control (BAC): Understanding BAC vulnerabilities
Ultimate Guide into Understanding and Identifying Broken Access Control Vulnerabilities
Today's estimated reading time is: 12 min
We've seen XSS vulnerabilities first as they are easy most of the time easy to spot.In the coming weeks, we're going to dive deeper into Broken Access Control vulnerabilities!They are generally also very easy to spot, as long as if you know what you're looking for, and are by nature, often high-severity vulnerabilities!Simply put, BAC or Broken Access Control vulnerabilities allow you to access and/or make changes to (sensitive) data, and functionalities or pages without being authorized to do so.A simple example would be you having access to order details of (all other/) another client on an online e-commerce webshop without their knowledge.
Today's post is brought to you by Nova SecurityThe attack surface management & vulnerability detection platform that saves you time, and earns you more bounties.Waitlist is open, join today ===> https://novasec.io/
Broken Access Controls:
Access controls are present within an application to prevent unauthorized users from accessing certain pages of functions.However, sometimes it is quite possible that during the implementation of a new feature, these access controls get forgotten about.That's why you should always aim at looking for vulnerabilities in new features as a beginner.
Some people mix up these terms quickly and it should be mentioned that these two terms authorization and authentication are NOT the same.
Authentication: Identifies the user and validates their identity (usually during the login process for example)
Meanwhile
Authorization checks whether you have the correct privileges to conduct an action or access data or a page (often after the login process, say only an admin user has access to certain pages or can edit blog posts).
Now that we covered what access control issues are and where they usually originate from, let's take a closer look at what kind of shapes and forms they can all come in.In next week's post, I will continue with this topic by explaining more in detail where you can find them and what payloads you can use.
Vertical Access Control issues:
Vertical access control issues are very easy to understand as the name says it all.You elevate your privileges vertically.So what does that mean? Let's take a look at a small example.Say you found a vulnerability that allowed you to take over any user account. Taking over an admin or staff account would elevate your privileges vertically as those types of accounts often have way more access than standard user accounts do.
Insecure Direct Object Reference (IDOR) issues:
Insecure Direct Object Reference or IDOR vulnerabilities are a form of horizontal access control issues.IDORs are usually found in APIs and websites. Exploitation often includes changing an account identifier to someone else's.Don't worry if you didn't fully get it, let's take a look at a quick example below:
In the image above, we can see the front end making a request to the API to fetch our user data.However, if we examine the request more carefully, we can see that a user ID is supplied as a request parameter.Removing the query parameter returns a 400 Bad Request, which tells us that the parameter is used by the backend to fetch our data!Supplying another user ID of our second test account confirms that this particular API endpoint is vulnerable to IDOR as it returns the user data associated with the second account.This is a major issue as anyone can view the private data of other users without being authorized.Besides reading data, IDORs can also allow us to modify, create or even delete someone else's data without being authorized to do so.Another thing to note is that user identifiers or user IDs can come in multiple forms and shapes. IDs can sometimes be email addresses, UUIDs, hashes or even signatures.It is always recommended to look at a request very carefully for any IDs.Do remember that IDORs usually lead to vertical access control issues.
File-based access control issues:
To view certain (sensitive) files, you must have the right privileges in order to view them.At least, that's what should happen. However, this is not always the case.Sometimes, developers deploy code to their hosting platform (such as Amazon S3 or Google GCP, etc.) or place sensitive configuration files in the same folder where the website is hosted.When this is the case, and no single server rule is set to block anyone from reading the file contents, it'll give you access to sensitive web config files or sometimes even backup files.This is sometimes the case for web config, GIT config data & htaccess/htpasswd files for example. These files often contain sensitive server configuration data and are not meant to be public.The same case for backup files (which often contain full source code of the backend for example).Very recently, I found a JAR file referenced in one of the javascript files which was obtained via a very unique approach (I will tell you more about it in a few weeks or so).It turned out that each new version of the compiled JAR file gets uploaded with the Java application.I was able to download and decompile it locally. It gave me access to the entire source code of the app (pentesting a web application when you have the source code is way easier and often allows you to find vulnerabilities that are very hard to find).File-based access control issues do not stop here, it is sometimes possible to get access to an unprivileged part of the web application through forced browsing.This attack often revolves around navigating to the path or file directly and with that bypassing any set restrictions.No issue if you didn't fully get it. Let me explain to you with a simple illustration:
As we can see in the image above, requesting the /admin route will redirect us back to /admin/login (watch the Location response header).Now say we did our homework today and found through content discovery another route called /admin/dashboard. Navigating it resulted in a 200 status code with a huge response body (meaning that we most likely successfully bypassed the login interface and got unauthorized access to the admin dashboard).This technique can be used in many examples, such as for example bypassing 2-factor authentication pages, email verification, etc.
Access control issues via controllable request parts:
Say, for example, a developer added for development purposes a query parameter that when supplied, would bypass an authentication form or display more and expose you to more functions or data than normal.For example, navigating to /dashboard would return you to your dashboard as usual, however, passing the ?debug=1 query parameter & navigating to /dashboard?debug=1 suddenly returns a lot of sensitive configs & debug data.Sometimes, web apps may allow you to view certain pages based on a request header such as the Referer header. Portswigger Labs has a perfect example of it.I've personally never encountered this with the Referer header before except with some custom headers that gave me access to other endpoints. You often find them referenced in JavaScript files.
Location-based access control issues:
This is a more uncommon or less detectable access control issue as your device's location matters.Basically, if your public IP matches a certain whitelist that the organization or company has set up, then you may get access to additional features that are only available in a specific country or region.You can test these by using different VPNs.I personally encountered this type of access control issue only once and I realized it was location-based after the triager couldn't reproduce my previously found vulnerabilities.It turned out that they whitelisted a public IP space and mine was included in it (I couldn't access the vulnerable staging website with a VPN for example).
Additional Resources:
Next week, I will add much more resources and writeups to start finding way more IDORs!
Thank you for reading this far!
I hope you've enjoyed this post! In next week's issue, I will continue to go through Broken Access Control issues! Stay tuned!
If you have any feedback, please do not hesitate to reach out! You can reply to this email or get in touch via Twitter DM!
Have a nice day and see you in the next post!
You can follow me on Twitter to receive upcoming updates on this newsletter:
Whenever you're ready, I can help you:
Get $200 in Digital Ocean credits to set up your Virtual Private Server:
Help you save time & earn more bounties using Nova Security: