Description

Broken Function Level Authorization (BFLA)
focuses on performing unauthorized actions rather than just accessing unauthorized resources, as seen in BOLA. It often involves requests that execute actions for other users, either at the same privilege level (lateral actions) or at an escalated role (e.g., administrative actions).

Key Aspects of BFLA:

1. Resource ID: Identifies a unique resource.
2. Requests Performing Actions: Look for requests that update, delete, or alter other users’ resources.
3. Missing/Flawed Access Controls: Exploiting BFLA requires the absence or misconfiguration of access

When hunting for BFLA:

• Focus on functional requests that involve creating, updating, or deleting resources.
• API methods like POST, PUT, DELETE, and GET with parameters, especially in administrative functions.

Testing Approach:

For BFLA, we use A-B-A testing to verify the impact on another user’s resources:

1. User A performs a valid action.
2. switch out to our UserB token
3. User B attempts to alter User A’s resources.
4. User A verifies if the action was successful.

Scenario

we have a function for updating video name,this function require authorization to access resources belong to given user:
In the captured request we can see that UserA’s video is specified by the resource ID “757”.

now let’s use UserB’s token and attemp to update the video name

we requested to update UserA's video, the server issued a successful response. However, the successful response indicated that UserB updated the name to the video identified as 758, UserB’s video. So, this request does not seem to be vulnerable.
We should investigate other request methods that can be used for this request.

Replacing PUT with DELETE -> This is an admin function. Try to access the admin API
now we dealing with admin api.So, what if we try udating the requesr to

Delete /identity/api/v2/admin/videos/758

Success! We have now discovered an admin path and we have exploited a BFLA weakness by deleting another user’s video
—