available about Broken Access Control vulnerabilities

Hello, my name is Alexander (aka bytehope). Before coming to bughunting, I worked in commercial development for five years. However, I have always been more interested in finding vulnerabilities, so now I spend my free time on bug bounty sites.

I decided to devote this article to vulnerabilities associated with Broken Access Control. You will learn that this is a very common bug that can manifest itself in a variety of ways. Of course, special emphasis will be placed on practice: I will show how to catch four different types of this vulnerability in the Web Security Academy labs. Let's start with the simplest examples, so the article is suitable for novice hunters. Feel free to look under the cat!

You can listen to the article, if it’s more convenient, turn it on video.

I advise you to look and previous issuesin which the guys from the Standoff Bug Bounty community remember their first steps in bughunting. If you're already on your way to winning awards, don't miss Oleg Ulanov's article about searching for SSRF vulnerabilities with a bunch of links to useful resources and tools.

Who broke access control

Access control is the process of making decisions about granting access rights. In other words, which users can view information or perform certain actions in the system.

Accordingly, we get Broken Access Control when this mechanism is broken: just anyone gets access to data and actions. For example, someone is looking at your hidden social media posts or adding Jason Statham quotes to your profile.

Such bugs are not uncommon in web applications. In 2021, Broken Access Control became the most common vulnerability according to the Open Web Application Security Project (OWASP). It can be found in a variety of guises, but today I will talk mainly about a subtype known as Insecure Direct Object Reference, or IDOR.

Elementary data theft

Our first example will be quite elementary: after all, we are just getting started with the bug bounty. It is associated with the use of integer values ​​as object IDs, which are quite easy to select at random or by brute force.

Let's say you registered on some website and received your username and password. Once you enter them in the page URL, you see your ID, the web application includes it in a database request and gives you access, for example, to a list of items in your cart or balance.

If you can enter another user’s ID instead of your own and the site gives you access to other people’s data, then it is vulnerable to the simplest vulnerability such as IDOR. Here's how we implemented it in our lab.

Defeating the Holy UUID

Let's try to complicate the task, because developers know about the dangers of integer IDs and try not to use them. Instead, they assign objects a UUID (aka GUID) – a universally unique identifier. Its main difference is that the UUID cannot be obtained by brute force, since it is a 128-bit number and consists of 32 characters.

Some developers stop there and believe that using a UUID alone guarantees security. However, even if we cannot find it out by brute force, there are other loopholes.

We showed one way to find out the UUID using the example of the second lab.

An interesting feature of this vulnerability is that the chance of UUID disclosure increases with the lifespan of the web application. Over time, any service acquires new functions, and it becomes increasingly difficult for developers to ensure that the identifier does not appear anywhere. This is also a typical example of incorrect access rights check.

Free case for now

The next example is even a little more intricate and is not related to going to a page or receiving someone else’s data, but to accessing files. In this case, the web application restricts access to the object, but not to the attachment itself.

Let’s imagine a website selling courses or a social network where you need a subscription to view some photos or videos. Sometimes such applications restrict access only to the object itself, such as a post, but not to the attachment within it, that is, a file. In this case we are also dealing with IDOR. An example of the implementation of such a vulnerability is available below (free for now!).

Leap for Privilege

Final example of the basicson the vulnerabilities of multi-stage application processes. Many sites work according to this principle, for example, when placing advertisements:

1. A user loads an ad.

2. Sends it to the administrator for review.

3. Receives approval and publishes the post.

In other words, the user cannot proceed to the final step without skipping the first two. Some developers rely too much on this logic and only enforce access control in steps 1 and 2. Accordingly, the attacker's goal is to jump straight to the third action.

Here's how this can be implemented using privilege escalation as an example.

Results

It may seem that vulnerabilities like Broken Access Control are too basic and do not pose a big threat. However, we have seen that they are very common and allow you to both steal other people’s data and increase privileges in the system. A hacker's access to the admin panel can not only ruin any advertising company, but also become the beginning of a more destructive attack. Many organizations are interested in the sustainability of their business and ready to pay for the bugs found. Therefore, searching for vulnerabilities is not only a contribution to our overall security, but also a chance to make good money. Join in!

Useful links

Finally, I want to share with you materials and tools that will help you look for vulnerabilities like Broken Access Control: