Search
K
Guides

API1:2023 - Broken Object Level Authorization (BOLA)

This is a vulnerability that happens when there is no validation made to do an operation on your API therefore revealing data the consumer shouldn't have access to

Understanding why this vulnerability exists

The reason this security risk exists is due to incorrect handling of authorization a user has over a set of resources. When requests that should be unique to a user are not authorized, they can be compromised. The following image shows an explanation of this vulnerability

BOLA - Broken Object Level Authorization OWASP API Security Top 10 - API1:2023 ✓ EXPECTED BEHAVIORUser A(Owner)AuthenticatesToken Valid ✓API GatewayGET /api/v1/objects/123Object 123Owner: User A✓ALLOW⚠ BOLA VULNERABILITYUser B(Attacker)No Auth CheckBypassed ✗API GatewayGET /api/v1/objects/123Object 123⚠ DATA EXPOSED✗BREACH⚠ CRITICAL: User B accessed Object 123 belonging to User A without proper authorizationThe API fails to verify owner of the object therefore exposing User A's data

Authentication vs Authorization

These are key concepts on the this vulnerability:

Authentication is the action to identifying a user, system or application. A commonly asked question to explain this is: Who are you? and following up with something that backs that up

Examples of Authentication:

  • Identification
  • Username & Passwords
  • API Keys
  • Tokens
  • Multi Factor Authentication

Authorization is level of permissions an entity has. In this case the question we make is: What am I allowed to do?

Examples of Authorization:

  • Roles-Based Access Control: a manager will have more permissions than a junior role. Same applies to an admin compared to an analyst
  • Access Control Lists: set of permissions that allow groups or users to access resources

Real World Examples

Example 1: AI Chat Applications (not an actual vulnerability)

URLs like https://ai/chat/3820504f-7a7d-4ff8-9fef-19ed6c9df4c0 can contain conversation tokens. Without proper authorization, sharing or guessing this URL could expose private conversations

Impact: Exposure of sensitive personal or business discussions, potentially including confidential data shared with the AI

Example 2: Current API Solution

Our current code has URLs like https://kong.nonamesec.org/secure/user/{user-id}/settings the user id should be something that a user does not have a control over as an input. Failure to authorize will expose other users data

Impact: Asserting another users id with no validation can lead to exposure of personal data

How to solve?

In the example #2 we are presented a vulnerability where the user id can be passed as a parameter. A solution for this would be a refactor of the URL and the server side handling this. The changes needed are:

  1. Changing the URL to: https://kong.nonamesec.org/secure/user/me/settings. This makes two things happen:
  • User is no longer allowed to insert values that control who is the user he is pulling from the API.
  • Make the session handle the request. What is a session? When we successfully authenticated into an application, the application should have a record of the user's interaction over a period of time. The session token should be a map of 1:1 with my user meaning that whenever we reach https://kong.nonamesec.org/secure/user/me/settings it should collect my session token that is tied to my user information
  1. ACLs are set of permissions that we can set over a resource. Through an ACL I can set a rule that whoever authenticates with a user that I select has control over the resource. Example like:

In Access Control Lists we can set that URL https://kong.nonamesec.org/secure/user/{user-id}/settings is only accessible for authenticated user: user@nonamesec.org

How did we actually remediated this in the current solution?

In this exercise where we are presenting an unsecure and secure API, we tried where possible to rely on Kong's API Gateway as the source of our protection, in some vulnerabilities this was not possible and changes to the server side were needed. In this case for the Broken Object Level Authorization (BOLA) we did manage to cover our vulnerable endpoints only through Kong Plugins without needing to provide a solution in the server side. The following table can be used to cover what controls we have in place:

Available on Kongs Plugin we utilized:

The two combine create a rule that only authenticated and authorized users can access their respective user information. But this still leave the door opened because there is not handling by the server side to control de Basic Auth session.