BFLA (Broken Function Level Authorization)

Hunting for BFLA involves searching for functionality to which you should not have access.A BFLA vulnerability might allow you to update object values, delete data, and perform actions as other users. To check for it, try to alter or delete resources or gain access to functionality that belongs to another user or privilege level.

Note that if you successfully send a DELETE request, you’ll no longer have access to the given resource . . . because you’ll have deleted it. For that reason, avoid testing for DELETE while fuzzing, unless you’re target- ing a test environment. Imagine that you send DELETE requests to 1,000 resource identifiers; if the requests succeed, you’ll have deleted potentially valuable information, and your client won’t be happy. Instead, start your BFLA testing on a small scale to avoid causing huge interruptions.

A-B-A Testing for BFLA

Like A-B testing for BOLA, A-B-A testing is the process of creating and accessing resources with one account and then attempting to alter the resources with another account. Finally, you should validate any changes with the original account. The A-B-A process should look something like this:

• Create, read, update, or delete resources as UserA. Note how the resources are identified and how the resources are requested.

• Swap out your UserA token for UserB’s. In instances where there is an account registration process, create a second test account.

• Send GET, PUT, POST, and DELETE requests for UserA’s resources using UserB’s token. If possible, alter resources by updating the properties of an object.

• Check UserA’s resources to validate that changes have been made by using UserB’s token. Either by using the corresponding web application or by making API requests using UserA’s token, check the relevant resources. If, for example, the BFLA attack was an attempt to delete UserA’s profile picture, load UserA’s profile to see if the picture is missing.

In addition to testing authorization weaknesses at a single privilege level, ensure that you check for weaknesses at other privilege levels. As pre- viously discussed, APIs could have all sorts of different privilege levels, such as basic user, merchant, partner, and admin. If you have access to accounts at the various privilege levels, your A-B-A testing can take on a new layer. Try making UserA an administrator and UserB a basic user. If you’re able to exploit BLFA in that situation, it will have become a privilege escalation attack.

Testing for BFLA in Postman