Products

Solutions

Resources

Search for API Security Tests

How to test for BOLA on an endpoint with weak enumerable user IDs?

In this blog you will learn how to test for Broken Object Level Authorization with weak enumerable user IDs.

In this blog you will learn how to test for Broken Object Level Authorization with weak enumerable user IDs.

BOLA-Test-Case-1
BOLA-Test-Case-1
BOLA-Test-Case-1

Jaydev Ahire

6 min read

6 min read

In this article, we will discuss an interesting test case where a weak user identifier can be used to perform a BOLA attack which could lead to data modification and sensitive data exposure. The attacker aims to compromise users' basket information.

General Severity:  Medium to Critical

OWASP Category: API1:2019 Broken Object Level Authorization

For practical demonstration, we will use Owasp Juice Shop vulnerable application. 

The web application has a feature where users can add their preferred juices to the basket. As an attacker, we will try to guess and retrieve information about other users by modifying IDs on the vulnerable REST API basket endpoint.

General Reproduction Steps:

1. Log in to the application and add any juice to the basket while capturing the request using Burp Suite (or any other proxy).

2. Observe the application was making a request to GET /rest/basket endpoint and send a request to a repeater for later use.

3. As you can see, the Apple juice we have added previously to our basked has a basket ID 1

4. Now, modify the basket ID number from 1 to 2.

5. Again modify the ID from 2 to 5. 

Observe that by modifying the ID number in an incremental fashion, we successfully exploited the BOLA vulnerability that allowed us to retrieve other users’ basket information. This happened because the basket endpoint above had a broken authorization flaw.

Impact:

Object references frequently include database IDs, which can be accessed by attackers to expose sensitive user information. You can also learn more about what BOLA is here.

Remediations:

  1. Developers implementing the API should implement a proper authorization mechanism. In the above case, the developer should check if the requested basket id is actually owned by the user and only then allow access.

  2. Perform active testing of your endpoints for BOLA vulnerabilities using automated testing products such as Akto. Do not deploy vulnerable changes that break the tests.

  3. Always use the UUID instead of simple sequential number IDs. UUIDs are Unique identifiers IDs, a mixture of letters and numbers that are impossible to guess.

In the next blog, we will learn how attackers can exploit BOLA by using other users’ unauthorized UUID.

In this article, we will discuss an interesting test case where a weak user identifier can be used to perform a BOLA attack which could lead to data modification and sensitive data exposure. The attacker aims to compromise users' basket information.

General Severity:  Medium to Critical

OWASP Category: API1:2019 Broken Object Level Authorization

For practical demonstration, we will use Owasp Juice Shop vulnerable application. 

The web application has a feature where users can add their preferred juices to the basket. As an attacker, we will try to guess and retrieve information about other users by modifying IDs on the vulnerable REST API basket endpoint.

General Reproduction Steps:

1. Log in to the application and add any juice to the basket while capturing the request using Burp Suite (or any other proxy).

2. Observe the application was making a request to GET /rest/basket endpoint and send a request to a repeater for later use.

3. As you can see, the Apple juice we have added previously to our basked has a basket ID 1

4. Now, modify the basket ID number from 1 to 2.

5. Again modify the ID from 2 to 5. 

Observe that by modifying the ID number in an incremental fashion, we successfully exploited the BOLA vulnerability that allowed us to retrieve other users’ basket information. This happened because the basket endpoint above had a broken authorization flaw.

Impact:

Object references frequently include database IDs, which can be accessed by attackers to expose sensitive user information. You can also learn more about what BOLA is here.

Remediations:

  1. Developers implementing the API should implement a proper authorization mechanism. In the above case, the developer should check if the requested basket id is actually owned by the user and only then allow access.

  2. Perform active testing of your endpoints for BOLA vulnerabilities using automated testing products such as Akto. Do not deploy vulnerable changes that break the tests.

  3. Always use the UUID instead of simple sequential number IDs. UUIDs are Unique identifiers IDs, a mixture of letters and numbers that are impossible to guess.

In the next blog, we will learn how attackers can exploit BOLA by using other users’ unauthorized UUID.

In this article, we will discuss an interesting test case where a weak user identifier can be used to perform a BOLA attack which could lead to data modification and sensitive data exposure. The attacker aims to compromise users' basket information.

General Severity:  Medium to Critical

OWASP Category: API1:2019 Broken Object Level Authorization

For practical demonstration, we will use Owasp Juice Shop vulnerable application. 

The web application has a feature where users can add their preferred juices to the basket. As an attacker, we will try to guess and retrieve information about other users by modifying IDs on the vulnerable REST API basket endpoint.

General Reproduction Steps:

1. Log in to the application and add any juice to the basket while capturing the request using Burp Suite (or any other proxy).

2. Observe the application was making a request to GET /rest/basket endpoint and send a request to a repeater for later use.

3. As you can see, the Apple juice we have added previously to our basked has a basket ID 1

4. Now, modify the basket ID number from 1 to 2.

5. Again modify the ID from 2 to 5. 

Observe that by modifying the ID number in an incremental fashion, we successfully exploited the BOLA vulnerability that allowed us to retrieve other users’ basket information. This happened because the basket endpoint above had a broken authorization flaw.

Impact:

Object references frequently include database IDs, which can be accessed by attackers to expose sensitive user information. You can also learn more about what BOLA is here.

Remediations:

  1. Developers implementing the API should implement a proper authorization mechanism. In the above case, the developer should check if the requested basket id is actually owned by the user and only then allow access.

  2. Perform active testing of your endpoints for BOLA vulnerabilities using automated testing products such as Akto. Do not deploy vulnerable changes that break the tests.

  3. Always use the UUID instead of simple sequential number IDs. UUIDs are Unique identifiers IDs, a mixture of letters and numbers that are impossible to guess.

In the next blog, we will learn how attackers can exploit BOLA by using other users’ unauthorized UUID.

Test for BOLA using the best proactive API Security product

Our customers love us for our proactive approach and world class API Security test templates. Try Akto's test library yourself in your testing playground. Play with the default test or add your own.

Share this post

Share this post

Share this post

Monthly product updates in your inbox. No spam.