What is Access Control?#
Access control is how we describe the constraints that we place on an authorized user in the context of accessing resources and performing actions.
When talking about web applications, this ability to restrict access depends on authentication and session management:
- Authentication: confirming that the user is who they claim to be.
- Session Management: determines which HTTP requests come from a particular user.
- Access Control: determines if the user is allowed to perform a specific action.
Access control vulnerabilities are somewhat common, but due to the size of applications and their diversity, they come in all shapes and sizes.
Horizontal vs Vertical#
We need to draw a distinction between control types, which will help us explain privilege escalation later.
Vertical access controls are restrictions placed on a users of a certain type. This could mean users labeled as author can post articles, but users labeled as viewers are only able to read those articles.
Horizontal access controls have to do with restricting actions to a singular user. An example would be a messaging website where a user should be able to change their own profile picture, but not someone else’s.
There are also context-dependent access controls that usually have to do with the state of the application at a specific point in time. For example, you shouldn’t be able to modify the contents of a shopping cart in an online shop after making a payment.
Examples of Broken Access Control#
Next, we will go over a few examples of how users might perform actions or access resources that they shouldn’t be able to.
Unprotected Functionality#
Website developers might assume that end users will only navigate to the admin portal by using a link only admin users have access to. You’ve probably seen how certain web frameworks use standard naming for admin panels and other locations on web applications can even disclose these names.
Even in the event that the name is very obscure and wouldn’t be in a wordlist, it is still possible to navigate to the page with enough time available.
This is essentially just obscuring how users access the admin page, which doesn’t really control whether or not someone is actually able to access it or perform actions once there.
Parameter-Based Access Control#
Some applications will determine your access when you log in, then store this information in user-controllable locations like:
- Hidden Fields
- Cookies
- Query String Parameters
Let’s say you register an account on a website and try to access an admin page but it returns an error message saying:
Error: Incorrect roleId
Try registering another account and seeing if you can just change the value on your own. For example if the registration POST request body looks like this:
{
"username":"gabe",
"password":"godopass",
"roleId":0
}
You might be able to just change the roleId parameter:
{
"username":"gabe",
"password":"godopass",
"roleId": 1
}
This could also be passed in the form of URL parameters for a GET request, it just has to do with the implementation.
Platform Misconfiguration#
Some applications restrict access based on the request method or the URL being used.
For example, if we have a website that allows admins to add users, but the application will now allow the /addUser endpoint to receive POST requests from certain users.
It is sometimes possible to override the URL being checked in the original URL by adding a header like X-Original-URL in the request.
This could allow you to access the /addUser endpoint without actually having it in the URL like this:
POST / HTTP/1.1
X-Original-URL: /addUser
---SNIP---
You also might be able to swap a POST method for a GET method in the request and just change whether or not the parameters are in the body or the URL.
Horizontal Privilege Escalation#
If we access other user accounts, we are performing horizontal privilege escalation. This can be done in a variety of ways if the application does not have a defense in place.
Imagine you change your name and the request has a URL like this:
http://vulnerable.com/editUsername?newname=gabe&userId=324
We might be able to change a user’s name if we know their user ID. If this user ID is disclosed anywhere on the site either directly or indirectly, this could cause a lot of problems.
Multi-Step Processes#
Web applications often utilize multiple-step operations, like asking you to verify if you’d like to change your username. Sometimes an application will properly implement access control on some steps of the process, but not others.
A more drawn out example would be if a web application ensures that only the specified user can navigate to their profile’s editing page, and only that user can save the new name in the field, but the application does not make sure that the Are you sure? request that actually submits the changes is verified.
Referer-Based Access Control#
Some applications restrict whether or not you can access and endpoint by using the Referer header in the request. Of course, if this is the only control being used, if you find out what the desired value is, you could bypass this protection.
Location Based Access Control#
Access controls can also be limited to a user’s location, which can be circumvented depending on the particular implementation.
Prevention#
We can go about preventing these kinds of vulnerabilities by applying these principles:
- Never rely on obfuscation alone for access control.
- Unless a resource is intended to be publicly accessible, deny access by default.
- Wherever possible, use a single application-wide mechanism for enforcing access controls.
- At the code level, make it mandatory for developers to declare the access that is allowed for each resource, and deny access by default.
- Thoroughly audit and test access controls to ensure they work as designed.