Broken access control is a common security vulnerability that occurs when an application fails to properly restrict access to its resources based on the user’s identity or role. This can lead to unauthorized users accessing sensitive data, modifying or deleting records, or performing actions that they are not supposed to do. Broken access control can have serious consequences for the security and integrity of an application and its users.
In this blog, we will explain what broken access control is, how it can be exploited, and how to prevent it in security testing. We will also provide some examples of broken access control vulnerabilities and how to fix them.
What is Broken Access Control?
Access control is the process of granting or denying access to resources based on the user’s identity or role. For example, an admin user may have access to all the features and data of an application, while a regular user may have access to only a subset of them. Access control can be implemented at different levels, such as:
- Authentication: verifying the user’s identity, such as by using a username and password, a token, or a biometric factor.
- Authorization: determining the user’s permissions, such as by using a role-based access control (RBAC) system, an access control list (ACL), or an attribute-based access control (ABAC) system.
- Auditing: logging and monitoring the user’s actions, such as by using a security information and event management (SIEM) system, or a web application firewall (WAF).
Broken access control is a security vulnerability that occurs when an application fails to implement one or more of these levels properly, or when there are flaws or weaknesses in the access control logic or design. This can allow an attacker to bypass the access control mechanisms and access resources that they are not authorized to access.
How can Broken Access Control be Exploited?
There are many ways that an attacker can exploit broken access control vulnerabilities, depending on the type and severity of the flaw. Some of the common methods are:
- IDOR (Insecure Direct Object Reference):
This occurs when an application exposes a reference to an internal object, such as a file, a record, or a key, in the URL or in a hidden form field, and does not check if the user is authorized to access that object.
For example, if an application uses a URL like https://example.com/profile?id=123 to display the user’s profile, an attacker can change the `id` parameter to access another user’s profile, such as https://example.com/profile?id=456. - Horizontal Privilege Escalation:
This occurs when an application allows a user to access resources or perform actions that belong to another user with the same role or level of privilege.
For example, if an application allows a user to edit their own profile, but does not check if the user is editing their own profile or someone else’s, an attacker can edit another user’s profile by changing the `id` parameter in the URL or in a hidden form field. - Vertical Privilege Escalation:
This occurs when an application allows a user to access resources or perform actions that belong to a user with a higher role or level of privilege.
For example, if an application allows a user to view their own orders, but does not check if the user is an admin or not, an attacker can view all the orders by changing the `role` parameter in the URL or in a hidden form field. - Missing Function Level Access Control:
This occurs when an application does not check if the user is authorized to access a specific function or feature of the application, such as a button, a link, or an API endpoint.
For example, if an application hides the `Delete` button from a regular user, but does not check if the user is an admin or not, an attacker can delete records by sending a direct request to the `Delete` API endpoint. - Forced Browsing:
This occurs when an application does not properly protect the files or directories that contain sensitive information, such as configuration files, backup files, or log files, and allows anyone to access them by guessing or brute-forcing the URL.
For example, if an application stores the database backup files in a directory like https://example.com/backups/, an attacker can download the backup files by browsing to that directory.
How to Prevent Broken Access Control?
The best way to prevent broken access control vulnerabilities is to follow the principle of least privilege, which means that each user should have the minimum amount of access and permissions required to perform their tasks. This can reduce the attack surface and the impact of a potential breach.
Some of the best practices to prevent broken access control in security testing are:
- Implement Strong Authentication and Authorization:
Use secure and standard methods to authenticate and authorize users, such as using HTTPS, hashing and salting passwords, using JWT or OAuth for tokens, and using RBAC, ACL, or ABAC for permissions. Avoid using predictable or guessable values for user IDs, roles, or keys, and use random or encrypted values instead. Validate the user’s identity and permissions on every request, and do not rely on client-side checks or hidden fields. - Use Indirect Object References:
Instead of using direct references to internal objects, such as IDs, keys, or filenames, use indirect references that are mapped to the user’s session or role.
For example, instead of using a URL like https://example.com/profile?id=123, use a URL like https://example.com/profile?token=abc, where token is a random or encrypted value that is associated with the user’s session or role. - Implement Proper Error Handling and Logging:
Do not expose sensitive information or internal details in error messages, such as stack traces, database queries, or file paths. Use generic and consistent error messages that do not reveal the cause or the location of the error. Log and monitor all the user’s actions and errors, and use a SIEM or a WAF to detect and prevent any suspicious or malicious activity. - Perform Regular Security Testing and Code Review:
Use automated and manual tools and techniques to test the application for broken access control vulnerabilities, such as using scanners, fuzzers, proxies, or browsers. Use different user accounts with different roles and privileges to test the application’s functionality and behavior. Review the application’s code and design to identify and fix any flaws or weaknesses in the access control logic or implementation.
Examples of Broken Access Control Vulnerabilities and Fixes
Here are some examples of broken access control vulnerabilities and how to fix them:
Example 1:
An online shopping application allows users to view their own orders by using a URL like `https://example.com/orders?id=123`, where `id` is the order ID. However, the application does not check if the user is the owner of the order or not, and allows anyone to access any order by changing the `id` parameter.
Fix:
The application should check if the user is the owner of the order or not, and deny access if not. Alternatively, the application should use indirect object references, such as using a token or a hash instead of the order ID.
Example 2:
A social media application allows users to edit their own profile by using a URL like `https://example.com/profile/edit`, where the user’s ID is stored in a hidden form field. However, the application does not check if the user is editing their own profile or not, and allows anyone to edit any profile by changing the hidden form field.
Fix:
The application should check if the user is editing their own profile or not, and deny access if not. Alternatively, the application should use indirect object references, such as using a token or a hash instead of the user ID.
Example 3:
A banking application allows users to view their own transactions by using a URL like `https://example.com/transactions?role=user`, where `role` is the user’s role. However, the application does not check if the user is an admin or not, and allows anyone to view all the transactions by changing the `role` parameter to `admin`.
Fix:
The application should check if the user is an admin or not, and deny access if not. Alternatively, the application should use indirect object references, such as using a token or a hash instead of the user’s role.
Conclusion
Broken access control is a common and serious security vulnerability that can compromise the security and integrity of an application and its users. It can be prevented by following the principle of least privilege and implementing strong authentication and authorization mechanisms. It can also be detected and fixed by performing regular security testing and code review.