Authorization
Check if users have only access to the resources and functionalities that they have rights to. A user should not be able to view resources from another user and should only be able to perform action assigned to their role. For example, we can create a resource with user A and try to access it logged as user B (A-B testing).
Check for nested JSON objects as it might bypass authorization restriction.
Parameters that pointing to resource can be found in:
URL
Headers
Body of request
Pay attention to any patterns found in resources identifiers such as incremental numbers.
Testing for BOLA depends of how the resources are identified how the resources are requested.
Side Channel BOLA
We may observe discrepancy in response when sending requests for existent vs non-existent resources. Observe the timing, the response status code and the response length. Information gleaned from how the web application responds to the requests sent can help an attacker to identify existing resources. This can be used later on to perform brute force attack or to gather some useful information.
Some information that can be valuable for an attacker are amongst others:
Usernames
Phone number
Products ID
Email
Account number
Etc.
BFLA
Check for functionalities that you should not have access to depending of your user role.
A-B-A Testing
Identification of BFLA follows an A-B-A flow. We can create a resource with user A, then modify it with user B token, then validate if any changes have been made using user A.
We should try modifying user's resources with all methods GET, POST, PATCH, UPDATE, DELETE, etc.
Privilege escalation attack
Check if we can perform any actions that are intentionally restricted to another role. For example, can we send administrative request as a low privilege user?
Postman Collection Runner
In Postman, we can use the Collection Runner to help us with identification of BOLA and BFLA vulnerabilities.
Perform all requests using the User A account > Send all requests potentially vulnerable to BOLA/BFLA in the Collection Runner. > Replace the token A with the user's B token. Replay all request and check for valid request.
Burp suite Match and Replace
The Match and Replace feature can be used to modify the user token on multiple requests at the same time. For example, we can modify token A for token B and replay all requests. Look for interesting requests that are used to access user's resources or that should be restricted to a specific role or user.
Last updated