.svg){kind=icon}
.svg){kind=icon}
What is Access Control?
Access Control plays a pivotal role in performing a penetration test.
In web applications, access control is defined as the process of managing users to access and restrict specific resources or functionalities within the application. It ensures the user has only the required privileges to perform actions or access specific parts (pages/resources) of the application while preventing unauthorized access or misuse.
Here are the core components under Access Control:
- Authentication
- Authorization
- Session Management
- User Roles & Permissions
We can divide the vulnerabilities related to Access Controls into two categories:
- Broken Access Controls
- Missing Access Controls
The image below depicts access controls and the categories, Proper Access Controls (PAC), Broken Access Controls (BAC), and Missing Access Controls (MAC) respectively.
Broken Access Control
Broken Access Control vulnerabilities generally occur when the access controls are in place but aren’t configured properly. Attackers can take advantage of this and perform malicious actions such as retrieving sensitive data of other users or other malicious activity. This usually occurs when there are mistakes in how the application works (flow), how it was made (designed), or how it was configured in setup.
When access controls are broken or not configured properly, it lets attackers get into the application and do things they're not allowed to (also known as unauthorized actions). This can lead to critical security issues, like unauthorized access to sensitive information.
Missing Access Control
Vulnerabilities associated with Missing Access Control (MAC) arise when a system lacks a robust access control mechanism. Developers might forget to add important checks like who is allowed to perform certain actions or if the data coming from the user to the application is safe.
These vulnerabilities let attackers get into the application, manipulate the data, or cause other problems. To prevent this, developers need to be careful and make sure they include strong access control checks, such as validating user identity, giving the proper and required permissions to employees or fellow developers, and validating the information for any issues before using it. This helps to keep the system safe from unauthenticated access and potential harm.
Examples of Access Control Vulnerabilities
- Insecure Function Level Authorization: This vulnerability occurs when an application lacks proper checks and authorization at different function levels. It can allow unauthorized users to access sensitive functionalities or APIs directly.
- Insecure Direct Object Manipulation (IDOR): This vulnerability allows an attacker to modify object identifiers or parameters associated with resources to gain unauthorized access to sensitive data. For example, manipulating URLs or form inputs to access or modify data to other users.
- Vertical Access Control Bypass (Vertical Privilege Escalation): This vulnerability arises when a lower-privileged user gains unauthorized access to resources or actions of higher-privileged users. For example, a user with no additional permissions is able to access and modify admin settings or sensitive data like resetting the passwords of other users.
- Horizontal Access Control Bypass (Horizontal Privilege Escalation): In this case, an attacker can access resources or perform actions of another user with the same level of privilege. For instance, one user viewing or editing the personal information of another user (with same permissions) without proper authorization comes under the same role group.
- Failure to Enforce Authorization/Validation Checks: When an application fails to enforce proper authorization checks at different layers (such as on API gateway, mid-tier applications and API level), it allows users to access restricted resources or perform actions they shouldn't have permissions for.
Access Control Issues with Real-World Examples
During my pentesting journey, I’ve encountered many vulnerabilities related to access control. Here are some examples from my real-life experience.
Example 1: Missing Authentication Checks - Remove the Address of Any User
While testing a JSP (Java Server Pages) application I came across a functionality via which a user can delete the address from their profile.
Intercepting the request in Burp proxy to analyze the remove address action.
Based on the intercepted request, it can be determined that the above request performs a GET action named removerAddress. This action is responsible for removing addresses from the user's account by referring to the aid (address ID).
To investigate the vulnerability further, the URL was copied and pasted into an incognito browser session without any authenticated user session.
The objective was to test if it was possible to remove an address from the victim's account without proper authentication.
*URL example: https://example.xxxxx/ajax?action=removeAddress&aid=value
Surprisingly, the address IDs were found to be in a numeric and incremental manner. This discovery implied that brute forcing the numeric IDs would likely allow unauthorized deletion of addresses from the user accounts.
Available addresses (Victim's Browser)
Visiting the above example URL (performing the remove address action from an unauthenticated session as an attacker):
Available addresses after the attacker deleted the address of the victim (Victim's Browser)
The application was unable to properly perform authentication checks while deleting the addresses of any users.
Understanding the issue with a code snippet
Here is the possible code on the backend for the specific action of removing an address:
The code checks if the requested action is to removeAddress by looking at the value of the action parameter. If it is, the code proceeds to remove the address.
The vulnerability lies in the fact that the code doesn't check if the user making the request is authenticated or authorized to delete the address (valid user). This means that anyone, even without logging in or with any permissions, can delete addresses from any user's account.
The code converts the address ID received as the aid parameter to an integer value. However, it doesn't perform any additional checks or validations before proceeding with the address removal.
After the address removal (which is not shown in the code snippet), the code sends a response indicating that the address has been successfully removed.
Mitigation:
The updated code snippets validates if the user is authenticated by verifying the presence of the loggedInUser attribute in the session.
Then, it checks if the requested action is to removeAddress by comparing the value of the action parameter.
If the user is authenticated and the action is valid, it proceeds with the access control validation. The code retrieves the loggedInUser attribute from the session, assuming it contains the username or identifier (such as user id) of the logged-in user.
Next, check to include additional authorization logic to validate whether the logged-in user is authorized to delete the address with the given ID. This could involve checking user roles, ownership of the address, or any other criteria that determine authorization, which means that it will perform proper authorization checks.
If the authorization checks pass, the code can proceed with the address removal logic.
If the user is not authorized, it returns a response indicating that the user is not authorized to remove the address.
If the user is not authenticated, it returns a response indicating that the user needs to log in to perform the action.
Example 2: Account Takeover due to Broken Access Controls
In this scenario, lower-level and admin user accounts (high privileges) were provided for testing the application. The lower-level user account has read-only access within the application. Upon analyzing the requests, it was discovered that the admin account had the functionality to reset passwords for other users from the manage user section.
Logged in as an Admin User
The HTTP request of the above password reset action looks like this:
Using the userid and password parameters the application performs the password reset functionality of the user linked to the provided userid.
However, at the read-only user's end, they can only view the admin's or other user's profile. There is no option available to manage any user's profile.
Logged in as a Read-only (Attacker) User
The attacker has permission to view other users from the user list in the application.
After clicking on the username of the victim, the attacker can intercept the request using Burp Suite and retrieve the user ID.
As an attacker, one can attempt to perform actions on behalf of the admin user. If the access controls are properly implemented, the application should restrict this functionality to only the admin user, preventing any unauthorized users from performing such actions.
Performing the action of password reset using the lower user's account using Burp Proxy.
The response to the above request with the attacker (read-only) user's session.
The account takeover of the admin user is successful due to Broken Access Controls in the application allowing a low-privilege user to reset anyone's password using only userID which can be retrieved from the other application functionalities.
Yet, the application should enforce the access controls properly so that only admin or users with password reset privileges can reset the password of other users.
Conclusion
Access control is an integral security mechanism that, when mishandled or overlooked, can open the doors to serious vulnerabilities that allow attackers to gain unauthorized entry, manipulate data, or cause other forms of harm to applications and their users.
Therefore it's vitally important for developers and security professionals to recognize various forms of access control vulnerabilities (Broken Access Controls or Missing Access Controls) as well as take proactive measures against them - this might involve properly implementing authentication and authorization checks, validating user inputs or restricting resources accessed only to authorized actions authorized actions only by authorized individuals or users only access resources or acting within their authorized capabilities.
