OWASP Broken access control explained

Hello ethical hackers, welcome to a new chapter of the OWASP Top 10 vulnerabilities series. In this article, we will explore OWASP Broken Access Control. You will learn the following:

• What is Broken Access Control?
• What are access control vulnerabilities, and how to exploit them?
• Attacks in the wild
• What is the impact of Broken Access Control?
• How to prevent it? 

I will keep enriching your mind with knowledge and skills with similar content, so make sure you don’t miss any chance and subscribe to our newsletter. 

What is Broken Access Control?

Let’s first understand the difference between Broken Authentication and Broken Access Control. There is a key difference to properly distinguish between them. The best way to explain that would be a simple example.

Suppose you have a penetration testing assignment. Quickly, you found an exposed administration dashboard without authentication. In this case, it is clearly an authentication issue. When the developer patches the authentication vulnerability, you log in as a normal user and find that you still have access to the dashboard. In this case, the developer forgot to validate if the user is authorized to access the admin dashboard.

Therefore, this vulnerability happens when the application fails to properly validate authorization after the user has been authenticated.

Broken Access Control vulnerabilities

Based on the definition above, there are many vulnerabilities under the Access Control category. This section covers some of them.

IDOR: Insecure Direct Object Reference

This vulnerability happens when the application doesn’t properly validate access to resources through IDs. For example, an application shows a purchase order to the customer using the /orders/12456 endpoint. However, the user whose order id is 12456 can also access other orders by simply changing the order id. This is the simplest scenario, but there are many other techniques to exploit an IDOR vulnerability.

CSRF: Client-Side Request Forgery

This is another vulnerability in the Broken Access Control category. In short, CSRF targets victim users, hence the term Client-Side, to unwillingly send a request from their own Web Browsers.

Generally, CSRF targets requests which change the state. For example, changing users’ data, updating an order, etc. When the application doesn’t verify if the user has forged the request, the attacker would impersonate the victim for that request.

CORS: Cross-Origin Resource Sharing misconfiguration

CORS allows making requests cross-origin, bypassing the Same Origin Policy (SOP). When there is a CORS misconfiguration, an attacker can impersonate a victim. In general, a CORS misconfiguration vulnerability doesn’t only perform state-changing actions, like CSRF does, but it also allows the attacker to read data. Moreover, when CORS misconfiguration chains with a CSRF vulnerability, an attacker can combine multiple requests to achieve highly impactful damage.

Broken Access Control attacks

There are a lot of examples which illustrate how prevalent this class of vulnerabilities is.

Firstly, let’s explore this Broken Access Control attack example. The bug bounty hunter demonstrates how he could take over any authenticated victim’s account using a misconfigured CORS. His exploit reads data from the user’ profile and then updates it. 

Then, in this Broken Access Control exploit, the attacker targets the profile update feature with a CSRF vulnerability. Therefore, he could change an authenticated victim’s email and take over his account.

Finally, this last report allowed an attacker to access the balances of unauthorized users. Notice how Starbucks clearly states that this issue targets authenticated but not authorized users.

Broken Access Control impact

If you’ve been following from the beginning of this article, you should have an idea of the impact of this vulnerability. In fact, they can target Confidentiality, Integrity and Availability, depending on the context. For example, an attacker can read sensitive data using an IDOR vulnerability or a CORS misconfiguration, which affects confidentiality. Besides, editing data of other users using a CSRF vulnerability would lead to an Integrity compromise.

Broken Access Control remediation

Preventing such a vulnerability can be complex because there are a lot of scenarios which can lead to it. Besides, while modern Frameworks protect against some vulnerabilities, like CSRF, they can’t protect against other vulnerabilities like IDOR. 

However, there general guidelines that I can advise you to respect:

• Learn what security protections your Web Framework offers and enable them.
• Protect all your endpoints using a role-based model which you should define once. That way, you reduce inconsistencies in your overall access control policy.
• Verify access to resources using IDs should always implement a verification step to make sure that the user has proper authorization.
• Deny access to your resources by default, unless you want them public.

For detailed information, OWASP explains some Access Control permission models and provides prevention measures in the OWASP Broken Access Control article.

That’s it! If you enjoyed learning with this article, make sure to share it with your network and subscribe to the newsletter to have fresh content delivered to you once it’s available. Until then, stay curious, learn new things and go find some bugs!