BOLA
Last updated
Last updated
Broken Object Level Authorization (BOLA) occurs when authorization controls are lacking or missing, UserA
will be able to request UserB’s
resources. APIs use values, such as names or numbers, to identify various objects. When we discover these object IDs, we should test to see if we can interact with the resources of other users when unauthenticated or authenticated as a different user. The first step toward exploiting BOLA is to seek out the requests that are the most likely candidates for authorization weaknesses.
When hunting for BOLA there are three ingredients needed for successful exploitation.
Resource ID: a resource identifier will be the value used to specify a unique resource. This could be as simple as a number, but will often be more complicated.
Requests that access resources. In order to test if you can access another user's resource, you will need to know the requests that are necessary to obtain resources that your account should not be authorized to access.
Missing or flawed access controls. In order to exploit this weakness, the API provider must not have access controls in place. This may seem obvious, but just because resource IDs are predictable, does not mean there is an authorization vulnerability present.
The third item on the list is something that must be tested, while the first two are things that we can seek out in API documentation and within a collection of requests.
Check the requests 1 by 1 for potential vulnerable endpoints that expose a pattern, e.g. an ID, either in the URL or the request body.
Create a user account (UserA
).
Use the API and discover requests that involve resource IDs as UserA
.
Document requests that include resource IDs and should require authorization.
Create another user account (UserB
).
Obtain a valid UserB
token and attempt to access UserA
's resources.
Make successful requests as UserA
with TokenA
and then change to TokenB
and try the same requests to UserA
's resources.