Preventing Broken Access Control: The No.1 Vulnerability in the OWASP Top 10 2021

By Bruce Kang, Associate Security Operations Engineer

In cybersecurity, the OWASP Top 10 is an invaluable resource for ensuring that web applications are secure. The list changes annually depending on what vulnerabilities become more prevalent. For me, one of the most interesting things about this year’s version is that Broken Access Control vulnerabilities jumped from No. 5 in 2020 to No.1. 

Now that it’s the most common weakness on the web, it’s more important than ever to understand how this type of vulnerability works—and how to prevent it. Let’s take a closer look.

What is Broken Access Control?

At its core, Broken Access Control is simply a scenario in which attackers can access, modify, delete or perform actions outside an application or systems’ intended permissions. Many vulnerabilities can be classified as a form of Broken Access Control, such as when normal users are able to access admin-only features by changing parameters in a URL, viewing or modifying another user’s data or privilege escalation.

A Simple Example of Broken Access Control

Let’s say a user can access their account settings for an arbitrary website via this URL:

In this example, the “id” parameter in the URL identifies which user’s settings are able to be changed. Each user has a unique ID number associated with their account.

So, what would happen if this user changed the URL to this?

This simple change could potentially give the user access to settings for a completely different user. In fact, in many web applications that use IDs to identify users, the admin user’s ID will likely be equal to 1. This means the attacker could potentially leverage this Broken Access Control vulnerability to gain full administrative access to the web application.

This vulnerability is called an IDOR (Insecure Direct Object Reference), a subset of Broken Access Control vulnerabilities. This usually occurs when different parts of a web application can be accessed through changing user inputs, such as a parameter inside a URL, as shown in the example above.

Broken Access Control: An Example Found in the Wild 

There have been several instances in which Broken Access Control vulnerabilities have led to real-world consequences. In August 2015, for instance, the security researcher Laxman Muthiyah found a Facebook vulnerability that allowed them to become an administrator of any Facebook page. This was done by making a POST request to a vulnerable API endpoint of Facebook.

The request can be found below:

In this case, anyone can use the graph.facebook.com/<page_id>/userpermissions API endpoint to edit their own permissions for a page. A user who is not already an admin should not have access to this ability to elevate other users’ privileges. However, it appears that this endpoint was not properly configured to prevent this from occurring. It’s an excellent example of Broken Access Control in the wild.

For more information, check out Laxman Muthiyah’s report here.

Broken Access Control: Accessing Restricted Content

Another example of Broken Access Control is one submitted by one of our own Synack Red Team members (sensitive info changed for client and researcher privacy). The researcher accessed premium content on the client’s website that should only have been accessible for paying subscribers. It was possible because even though the base URL of the website was accessible only to paying users, the endpoints were accessible to anyone.

The base URL of this application was:

https://client-website/directory-1/

This was essentially the homepage for a service where users could access different resources under the directory named “directory-1.” If the user did not pay for access, then the content was not viewable.

However, by browsing directly to one particular service of the page, the researcher could access all the content in the sub-directory:

https://client-website/directory-1/service-1/

This technique is referred to as “forced browsing.” This happens when an unauthenticated user browses to a URL that should be accessible only to authenticated users. Attackers can find these endpoints usually through the usage of a directory brute forcing tool that will find the web application directories by using a wordlist to automatically navigate to endpoints and see if they lead to valid responses. If the response is not a 404, then the endpoint likely exists. There is also an OSINT method called “Google Dorking,” where attackers use special Google search queries to find “hidden” endpoints. Normally, the user should be redirected or denied access when attempting to access a directory they do not have access to, but this was not the case in this example.

This is a clear example of Broken Access Control, as a non-paying user should not be able to view content that only those who have paid should have access to.

Broken Access Control: Compromising an Entire Network

Another one of our SRT members found a very interesting and high-impact Broken Access Control vulnerability resulting in the possible compromise of several machines in the client’s network (sensitive info changed for client and researcher privacy). This was done by finding an administrator’s authentication token for an API used for patch management.

The researcher found that the endpoint https://client-website.com/api/userData contained the authentication token of several users, including the main administrator. This in turn gave the researcher the ability to use the API’s more restricted functionality. This included being able to enumerate the users and machines on the client’s network, viewing patch data, and even the ability to execute malicious patches or scripts on these machines. In theory, this exploit could have very well been leveraged to take over the entire internal network that the API had access to.

Enumerating users in Active Directory with the authToken:

In this scenario, this type of user data should not be accessible publicly, especially for an API that has the capability to cause such a massive impact on an entire network. This is the reason why it is best practice to deny by default all resources that are not public.

Broken Access Control: Vertical Privilege Escalation

Broken Access Control vulnerabilities can also result in vertical privilege escalation, as found by another one of our SRT members. In this particular example, a settings page of a lower privileged user was exploited to gain administrative privileges on a web application. This was done by modifying the PUT request that was being sent to an API, which was meant to be used to save any changes the user made to their profile.

The PUT request from the settings page looked similar to this:

As you can see, the PUT request contains various information about the user, including the level of access that they have. When the request goes through, this information is saved for that user in the API. Some of these parameters, such as the “userRole” value, are not able to be edited via the application’s user interface. However, the request can be intercepted using a proxy, which then can be modified to have all of these values changed. The most important value that can be changed is the “userRole” parameter.

Thus, the researcher was then able to send this request to the API instead:

This small change from “user” to “admin” elevated their role to be an admin user on the application. In turn, this allowed the researcher to be able to view and modify data that they had previously no access to. A normal user should not be able to modify the “userRole” field on the API endpoint, and instead should be met with an error when attempting to do so. This field was only protected on the application’s user interface, but not on the actual API endpoint that stores this information.

Final Thoughts On Testing For Broken Access Control

Broken Access Control vulnerabilities can lead to serious consequences and organizations definitely do not want malicious users having more access to applications than intended. 

Luckily, there are many different ways to mitigate the chances of having a Broken Access Control vulnerability in web applications. OWASP has a list of these defenses here. However, it is important to understand how these vulnerabilities work in order to recognize and prevent them from existing in the first place.

Broken Access Control vulnerabilities can be found through crowdsourced penetration testing from Synack. With the elite skills of the SRT and the convenience of the Synack Platform, organizations are able to efficiently perform vulnerability discovery with a truly adversarial perspective.

Synack Campaigns provide an on-demand way to augment internal teams and address specific security tasks with the help of Synack’s elite researchers. Through Synack Campaigns that are based on OWASP testing guidelines, organizations are able to target Broken Access Control—among many other top OWASP vulnerabilities—and receive actionable reports that reveal these and other weaknesses. 

Reach out today to get started.