BOLA (Broken Object Level Authorization)

If you see that the API lists resources following a certain pattern, you can test other instances using that pattern. For instance, say you notice that after making a purchase, the app uses an API to provide you with a receipt at the following location: /api/v1/receipt/135. Knowing this, you could then check for other numbers by using 135 as the payload position in Burp Suite or Wfuzz and changing 135 to numbers between 0 and 200.

When you’re on the hunt for BOLA vulnerabilities, remember that they aren’t only found using GET requests. Attempt to use all possible methods to interact with resources you shouldn’t be authorized to access. Likewise, vulnerable resource IDs aren’t limited to the URL path. Make sure to consider other possible locations to check for BOLA weaknesses, including the body of the request and headers.

Locating Resource IDs

So far, this book has illustrated BOLA vulnerabilities using examples like performing sequential requests for resources:

GET /api/v1/user/account/ 1111 
GET /api/v1/user/account/ 1112

Pay close attention to the information the API provider is using to retrieve resources, as it may not be so obvious. Look for user ID names or numbers, resource ID names or numbers, organization ID names or numbers, emails, phone numbers, addresses, tokens, or encoded payloads used in requests to retrieve resources.

Keep in mind that predictable request values don’t make an API vulnerable to BOLA; the API is considered vulnerable only when it provides an unauthorized user access to the requested resources. Often, insecure APIs will make the mistake of validating that the user is authenticated but fail to check whether that user is authorized to access the requested resources

Valid Requests for Resources and the Equivalent BOLA Test

Type	Valid request	BOLA test
Predictable ID	GET /api/v1/account/ 2222 Token: UserA_token	GET /api/v1/account/ 3333 Token: UserA_token
ID combo	GET /api/v1/ UserA /data/2222 Token: UserA_token	GET /api/v1/ UserB /data/ 3333 Token: UserA_token
Integer as ID	POST /api/v1/account/ Token: UserA_token {"Account": 2222 }	POST /api/v1/account/ Token: UserA_token {"Account": [3333]}
Email as user ID	POST /api/v1/user/account Token: UserA_token {"email": " [e-mail]"}	POST /api/v1/user/account Token: UserA_token {"email": " [e-mail]
Group ID	GET /api/v1/group/ CompanyA Token: UserA_token	GET /api/v1/group/ CompanyB Token: UserA_token
Group and user combo	POST /api/v1/group/ CompanyA Token: UserA_token {"email": " userA@CompanyA .com"}	POST /api/v1/group/ CompanyB Token: UserA_token {"email": " userB@CompanyB .com"}
Nested object	POST /api/v1/user/checking Token: UserA_token {"Account": 2222 }	POST /api/v1/user/checking Token: UserA_token {"Account": {"Account" :3333}}
Multiple objects	POST /api/v1/user/checking Token: UserA_token {"Account": 2222 }	POST /api/v1/user/checking Token: UserA_token {"Account": 2222, "Account": 3333, "Account": 5555 }
Predictable token	POST /api/v1/user/account Token: UserA_token {"data": "DflK1df7jSdfa1acaa"}	POST /api/v1/user/account Token: UserA_token {"data": "DflK1df7jSdfa2dfaa"}

A-B Testing for BOLA

What we call A-B testing is the process of creating resources using one account and attempting to retrieve those resources as a different account. This is one of the best ways to identify how resources are identified and what requests are used to obtain them.

The A-B testing process looks like this:

• Create resources as UserA. Note how the resources are identified and how the resources are requested.

• Swap out your UserA token for another user’s token. In many instances, if there is an account registration process, you will be able to create a second account (UserB).

• Using UserB’s token, make the request for UserA’s resources. Focus on resources for private information. Test for any resources that UserB should not have access to, such as full name, email, phone number, Social Security number, bank account information, legal information, and transaction data.

A variation on A-B testing is to create three accounts for testing. That way, you can create resources in each of the three different accounts, detect any patterns in the resource identifiers, and check which requests are used to request those resources, as follows: • Create multiple accounts at each privilege level to which you have access. Keep in mind that your goal is to test and validate security con- trols, not destroy someone’s business. When performing BFLA attacks, there is a chance you could successfully delete the resources of other users, so it helps to limit a dangerous attack like this to a test account you create. • Using your accounts, create a resource with UserA’s account and attempt to interact with it using UserB’s. Use all the methods at your disposal.

Side-Channel BOLA

we discussed how APIs can reveal the existence of resources through middle- ware like X-Response-Time. Side-channel discoveries are another reason why it is important to use an API as it was intended and develop a baseline of normal responses.

In addition to timing, you could use response codes and lengths to determine if resources exist. For example, if an API responds to nonex- istent resources with a 404 Not Found but has a different response for existing resources, such as 405 Unauthorized, you’ll be able to perform a BOLA side-channel attack to discover existing resources such as usernames, account IDs, and phone numbers.