Primer on Broken Access Control vulnerabilities and how to find them

Reading Time: 7 Minutes

Introduction

In this article, we will be focusing on broken access control vulnerabilities and providing multiple examples of how to detect them. It is important to note that broken access control vulnerabilities have become increasingly prevalent in recent years. In fact, they are currently ranked first in the OWASP Top 10 list of vulnerabilities. This is a significant jump from their 5th-place ranking in 2017.

This write-up is a must-read for anyone interested in how to secure their applications from such vulnerabilities or finding how to detect them, including researchers and software developers, as broken access control vulnerabilities were found in a staggering 94% of tested applications in 2021.

Access Control

Access control refers to the process of restricting access to certain resources or actions based on a set of rules and permissions. It is a way of ensuring that only authorized individuals or entities are able to access sensitive information or carry out specific tasks.

In the context of web applications, access control is dependent on two factors:

• authentication
• session management

Authentication is the process of verifying the identity of a user and confirming who they say they are, while session management keeps track of the same user’s subsequent HTTP requests.

Once these two elements are in place, access control can be implemented to determine if the user is allowed to perform a specific action or access a specific resource.

Source: OWASP

Access control categories

In order to show some examples of broken access control vulnerabilities we first have to address the access control types.
Access controls can be broadly categorized into three types:

• vertical
• horizontal
• and context-dependent.

Vertical access controls are designed to restrict access to certain functionality based on the user’s role or privilege level. These controls ensure that users have access only to the features and actions that are appropriate for their level of authority. For example, in a company’s internal management system, managers might be able to approve leave requests, while regular employees can only submit them.

Horizontal access controls, on the other hand, regulate access to specific resources based on user permissions. In this type of access control, different users are granted access to different subsets of resources of the same type. For example, in a file-sharing system, a user might be able to access and edit their own files, but not those of other users.

Context-dependent access controls take into consideration the current state of the application or the user’s interaction with it when determining access permissions. These controls are implemented to prevent users from performing actions in the wrong order or in a way that could compromise the system’s security. For example, in a school management system, students might be able to view their grades after the teacher has released them, but not before.

Broken access control vulnerabilities

Broken access controls occur when a user gains unauthorized access to resources or actions that are restricted to them.

Vertical privilege escalation

Vertical privilege escalation occurs when a user is able to access functionalities that they are not authorized to access.

Lack of protection over sensitive functionality

In some cases, applications fail to enforce proper security over sensitive functionalities, making them susceptible to vertical privilege escalation. For instance, an administrative page may have links to administrative functionalities but not for regular users, but users can still access these functionalities by simply navigating to the relevant admin URL.

For example, consider a website with sensitive functionalities located at:
https://vulnerable-website.com/management

This URL may be accessible to all users, not just administrators who have a link to it in their user interface.

In other cases, the URL may be revealed in other sources, such as in the site’s robots.txt file:
https://vulnerable-website.com/robots.txt

Another method of concealing sensitive functionalities is through the use of obscure URLs, a technique known as security through obscurity. Hiding sensitive functionalities, however, does not guarantee effective access control as users may still find the obscured URL through various means.

For instance, a website with administrative functionalities located at:
https://vulnerable-website.com/secret-admin-page-xg122
This URL may not be easily guessable by an attacker, but it may still be disclosed in the website’s JavaScript code, as seen below:

<script>
var isAdmin = false;
if (isAdmin) {
        …
        var adminLink = document.createElement(‘a’);
        adminLink.setAttribute(‘https://vulnerable-website.com/secret-admin-page-xg122’);
        adminLink.innerText = ‘Admin panel’;
        …
}
</script>

This script will add a link to the user’s interface if they are an administrator, but the script including the URL is visible to all users regardless of their role.

Inadequate Parameter-based Access Control

Applications that use parameters to determine user access rights or roles are vulnerable to exploitation. This information is often stored in a user-controllable location such as a cookie, query string, or hidden form field, while the application makes subsequent access control decisions based on the value submitted by the user.

For instance, if the application allows a user to access the administrator section of a website by adding “admin=true” to the URL, this can be easily manipulated by a malicious user to gain access to sensitive areas of the website:
https://vulnerable-website.com/login?admin=true

Similarly, an application that grants access to certain pages or functionalities based on the value of a “role” parameter could also be exploited by a malicious user:
https://vulnerable-website.com/pages?role=3

This approach to access control is unreliable as the user is able to modify the values and gain unauthorized access to sensitive functionality.

Misconfigured Platform-level Access Control

In some applications, access control is implemented at the platform level by limiting access to specific URLs and HTTP methods based on the user’s role.
For instance, an application might have the following rule in place:
DENY: DELETE, /secret-info, non-admins

This rule blocks access to the DELETE method on the URL /secret-info, for users who are not in the admin group. However, various problems can arise, leading to breaches in access control.
One issue is the use of non-standard HTTP headers that can alter the original URL request, such as X-Modified-URL and X-Replace-URL.

If a website implements strict front-end controls based on URL but allows for alteration via request headers, it may be possible to bypass access controls with a request like this:
DELETE / HTTP/1.1
X-Modified-URL: /secret-info
…

Another vulnerability is related to the HTTP method used in the request. Some websites may be flexible with alternate HTTP methods when performing actions, even if access is restricted based on URL and HTTP method. In this case, an attacker could potentially bypass access control by using a different method, such as GET, to perform actions on a restricted URL.

Horizontal Privilege Escalation

Horizontal privilege escalation refers to a situation where a user gains unauthorized access to resources belonging to another user with the same level of access.
Consider an online shopping platform where each customer has a personal account page displaying their order history and other personal information. If a customer is able to view the order history and personal information of another customer simply by changing the URL to their own account page, this would be an example of a horizontal privilege escalation vulnerability.

Attack Techniques

An attacker might exploit horizontal privilege escalation vulnerabilities using various methods, similar to those used for vertical privilege escalation attacks.
For example, consider a URL like this:
https://insecure-website.com/profile?username=johndoe

An attacker can modify the username parameter to the username of another user, potentially accessing sensitive information such as their personal details, contact information, and transaction history. In this scenario, the attacker is able to escalate their privileges horizontally by gaining access to resources that are meant for another user.

Unique Identifiers

In some cases, applications use unique identifier values instead of predictable values such as incrementing numbers to identify users. For instance, they might use globally unique identifiers (GUIDs) instead. While it might not be possible for an attacker to predict the identifier for another user, they might still find it disclosed elsewhere in the application, such as in user messages or reviews.

For example, consider a social media platform that assigns each user a unique GUID for identification purposes. An attacker might come across a user review where the author’s GUID is included in the URL of the page: https://socialmedia.com/reviews/user/7b5632d0-c7a3-45f9-a3e1-a87c56e93f01. The attacker can use this information to access the author’s profile page, potentially gaining access to sensitive information such as personal details and private messages. This is an example of horizontal privilege escalation through the discovery of unique identifiers disclosed in the application.

Redirection to the Login Page

In some cases, applications detect when a user tries to access a restricted resource and redirects them to the login page. Although the redirection protects the resource from unauthorized access, it might still disclose sensitive information belonging to the targeted user, making the attack successful. For example, suppose a company has an internal website for employees to access their payroll information. If an unauthorized user tries to access another employee’s payroll information, the application detects the attempt and redirects the user to the login page. However, the URL in the browser address bar still displays the sensitive information (such as the employee’s payroll ID) that the attacker was trying to access. The attacker can then use this
information for further attacks, potentially compromising the privacy and security of the targeted employee.

IDOR

Insecure Direct Object References (IDOR) occur when an application uses user input to access objects directly without proper security measures. This type of vulnerability allows an attacker to bypass access controls and potentially view sensitive information.

Direct reference to system files

A website might have a URL like https://insecure-website.com/document?file_id=112233,
where the file_id is directly used to access a file stored in the system. An attacker can modify the file_id value and gain access to restricted files, leading to horizontal privilege escalation.

Referer-based access control vulnerabilities

Referer-based access control is a security weakness found in web applications that use the HTTP Referer header to control access to sensitive data or functionality. This type of access control is not secure and can be easily exploited to allow unauthorized access.

Attack Mechanism

The Referer header is a field in the HTTP protocol that identifies the page from which a request is made. A web application is vulnerable to a referrer-based access control attack if it relies solely on the Referer header to control access to sensitive resources. An attacker can exploit this vulnerability by forging a request to sensitive pages or forms by modifying the Referer header.
For example, consider a social media website, “socialhub.com.” The site restricts access to the “/private-profile” page to only users who have been referred from the “/friend-list” page. An attacker wants to view the private profile of another user without being friends with them. The attacker can craft an HTTP request to the “/private-profile” page, altering the Referer header to show that it was referred from the “/friend-list” page, thus, granting access to the private profile.

Transitioning from Horizontal to Vertical Privilege Escalation

It’s possible for a horizontal privilege escalation attack to escalate into a vertical privilege escalation by compromising a more privileged user.

Horizontal to vertical privilege escalation occurs when an attacker takes advantage of a horizontal privilege escalation vulnerability to gain access to a higher level of privileges. Instead of just accessing resources belonging to another user, the attacker aims to compromise a more privileged user and gain administrative access.

For example, an attacker gains access to an employee’s account by exploiting a horizontal privilege escalation vulnerability and then uses this access to target the account of a system administrator. By successfully compromising the administrator’s account, the hacker can now perform actions with elevated privileges such as modifying system configurations or stealing sensitive data, thus resulting in a vertical privilege escalation.

Lab example walkthrough – Referer-based access control

This lab was created by PortSwigger

• Accessing the lab – vulnerable webpage

• Log in with the admin creds
• Open your burp suite
• Navigate to the admin panel

• Try to upgrade carlos (user) – intercept the request with burp and send it to the repeater.

• Login to a new browser session with your normal user (wiener – peter), and intercept the request
• Copy the session cookie of the normal user

• Add the non-admin cookie to the first request, change the name of carlos to the name of the non-admin user(wiener), and send the request.

• The lab is solved, and wiener (normal user) is now an admin.

This example illustrates how a vulnerability in referer-based access control can be exploited by attackers to escalate privileges and potentially compromise the entire web application.

Prevention

• Implement strong authentication and authorization mechanisms: This can include using secure passwords, two-factor authentication, or biometric authentication.
• Limit access to sensitive resources: Only grant access to those who need it to perform their job duties and regularly review and revoke access as necessary.
• Ensure input validation: Validate all inputs to prevent injection attacks and ensure that data is within expected bounds.
• Use secure encryption: Encrypt sensitive data both in transit and at rest to protect it from unauthorized access.
• Implement role-based access controls: Assign roles to users based on their job duties and restrict access to sensitive resources based on those roles.
• Log and monitor access to sensitive resources: Regularly monitor access to sensitive resources and keep logs of who accessed what and when.
• Educate users: Provide training on security best practices and educate users on how to avoid security threats and how to respond if they detect a security incident.
• Conduct regular security assessments: Regularly conduct security assessments to identify vulnerabilities and assess the effectiveness of security controls.
• Have a plan in place for responding to security incidents, including identifying the appropriate steps to take, who to notify, and what information to gather.

Last Thoughts

In conclusion, access control vulnerabilities are a serious security risk that can be exploited by attackers to gain unauthorized access to sensitive data and functionality. To prevent these vulnerabilities, it is essential to shift security left in the development cycle and implement proper access controls early on in web app development. This includes denying requests by default and rate-limiting APIs.

However, designing and managing access control requires careful consideration of various requirements and is a complex process that requires human expertise and decision-making, making it prone to errors.

Application developers must know their access control policies and explicitly define who can do and/or access what to avoid access control vulnerabilities in their applications. By taking a proactive approach to access control, organizations can better protect their systems and data from unauthorized access.

We hope that this write up has taught you something new. If you enjoyed it, the best way that you can support us is to share it! If you’d like to hear more about us, you can find us on LinkedIn, Twitter, YouTube.

 

Are you a security researcher? Or a company that writes articles about Cyber Security, Offensive Security (related to Information Security in general) that match with our specific audience and is worth sharing? If you want to express your idea in an article contact us here for a quote: [email protected]