API-01 Broken Object Level Authorization

Broken Object Level Authorization, or BOLA, is the top API security threat on the OWASP API Security Top 10. It occurs when an attacker can successfully make a request for a data object that should be restricted.

What is a data object?

Programmers frequently call a collection of related data an object. An example of this could be the profile associated with your account at an online retailer. Your profile object likely contains items such as your full name, username, customer ID, shipping & billing address, and so on. Developers use these objects to access information on customers in their programs and APIs.

Using an online retailer example, an attacker could use their identity represented as a token in an API request to ask for (and receive) the profile of other users of the online retailer. To achieve this, the attacker will replace their customer ID with a customer ID of another user. The attacker could use their token and the customer ID of a legitimate user to gain access to legitimate user’s profile data.

Why is broken object level authorization important?

Unfortunately, this is a very common issue with APIs and is frequently used by attackers to gather large amounts of sensitive data. Extending the online retailer example above, once the attacker can successfully read another user’s profile data, they will automate the requests and gather tens if not hundreds of thousands of records. In recent history, a major telco in the United States had 2.3 million customer records leaked via an insecure API.

Additionally, many developers of APIs that support mobile and web applications mistakenly believe that only the mobile app or website will make ‘proper’ requests. Unfortunately, attackers are not restricted to only using the official apps and typically use specialized tooling to observe and modify data coming to and from APIs.

Example

Continuing with the online retailer example, below is a valid request where Mallory asks for his own profile data using his customer ID 1041864:

Request

POST https://example.com/api/v2/customer/profile HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */* Accept-Language: en-US,en;q=0.5 Content-Type: application/json
Authorization: BearereyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJlZEBleGFtcGxlLmNvbSIsImlhdCI6MTY1ODQ2MDMzMCwiZXhwIjoxNjU4NTQ2NzMwfQ.m0ha0L89xuLpLlLlybcaD2SfKp23BZfe_Hjjs- PprCN2sDvxpmWAcemN5yOq-nhx78Iu8EzLIJbqqc1d-q10UA
Connection: keep-alive
Body:{id:1041864}

Response

HTTP/1.1 200
Server: openresty/1.17.8.2
Date: Fri, 22 Jul 2022 03:25:30 GMT
Content-Type: application/json
Connection: keep-alive
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
{
'id': 1041864,
'name': 'Mallory',
'email': 'mallory@evil.com',
'dob': '04-15-1990',
'phone_number': 555-555-0666,
'ssn': 000-12-3456,
'card_on_file': false,
'credit_card': null,
'loyalty_points': 0,
'tax_state': 'Wyoming'
}

However, Mallory then repeats the request and only changes the customer ID to Alice’s customer ID 1041865:

HTTP/1.1 200
Server: openresty/1.17.8.2
Date: Fri, 22 Jul 2022 03:25:30 GMT
Content-Type: application/json
Connection: keep-alive
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
{
'id': 1041864,
'name': 'Mallory',
'email': 'mallory@evil.com',
'dob': '04-15-1990',
'phone_number': 555-555-0666,
'ssn': 000-12-3456,
'card_on_file': false,
'credit_card': null,
'loyalty_points': 0,
'tax_state': 'Wyoming'
}

With proof that a BOLA Vulnerability exists, Mallory can now automate the attack by repeatedly calling the /api/v2/customer/profile API endpoint and including a different customer ID with each request. In this example, customer IDs count up so determining other customer IDs only takes adding or subtracting 1 from a valid customer ID.

How to prevent broken object level authorization

Attackers and penetration testers look for BOLA vulnerabilities by inspecting API traffic for data that appears to be an ID or identifier for some data used by the API.  Generally, these IDs are numeric but can also be strings (a set of characters) or unique identifier like a UUID

What is a penetration tester?

A penetration or pen tester is someone who simulates the activities of a malicious attacker to discover security weaknesses in computer systems, applications, or APIs. The goal of pen testing is to discover and remediate security issues before malicious actors exploit them.

Once IDs have been discovered, the attacker makes new requests with altered ID values. If the API is secure, those requests will fail, typically with a ‘403 Forbidden’ response. If the request is allowed and the data should not be available to the user account that made the request, BOLA is present.

Other methods employed by attackers include creating data as one user, noting down its ID. Then the attacker will request the ID for the original user’s data with a different user. This technique can be used when guessing or discovering IDs is difficult. Other signs of potential BOLA issues include difference in response time, length of response, and HTTP response code as shown below:

401 ‘Unauthorized’ – the user is not authorized for the data requested

404 ‘Not Found’ – the requested data does not exist

403 ‘Forbidden’ – the user does not have access to the data

405 ‘Method Not Allowed’ – the user does not have access to make the request

How to defend against broken object level authorization

BOLA attacks tend to look very similar to normal API requests – with the only thing changing is a single ID field.  For many network inspecting devices such as WAFs and firewalls, the level of inspection is not deep enough to notice the subtle change of an ID. Since most network devices have to operate a line speed, the requirement to not delay production traffic generally removes the ability to provide deep enough inspection.

API specific runtime tools allow for deeper inspection and are required to provide full coverage. The inspection needs to be able to correlate the identity of the client, generally an API token, with the identity of the resource being requested.  Returning to our example, API runtime needs to know that the token used by Mallory shouldn’t request the customer ID of Alice.

Another way attackers can provide clues to their activity is by the inevitable authorization failures as they probe for potential BOLA vulnerabilities. Because one API request is vulnerable to BOLA doesn’t necessarily mean all of those APIs requests are vulnerable. As an attacker works to determine which API endpoints are vulnerable, they generally have several requests that fail with authorization errors. The errors happen when API endpoints have proper authorization checks. So, if endpoints are monitored for authorization errors, a spike in those errors can indicate that attackers are testing the API for BOLA.

If deep inspection is combined with machine learning, AI or other computer learning methodologies, additional detection of malicious activity can be discovered. By combining deep inspection with computer learning, attack patterns can be found.  In the case of BOLA, a single client or computer that makes two or more similar requests in a short period of time that only vary by the IDs in the request is very likely conducting an attempted BOLA attack. This is especially true when the same authorization token is used for both requests. Why would the same computer make a request for Mallory then a request for Alice right after another but only use Mallory’s token?  Most clients only act on behalf of a single user and use a single authorization token.

How Noname can help

APIs are an integral part of the enterprise software ecosystem. They are the key ingredient in digital transformation. APIs can also be a source of cybersecurity risk. Their open nature makes them a frequent target of hackers who want to access the data and applications that sit behind them. API security best practices make it possible to mitigate a great proportion of API risk. To work, these practices need to focus on the complete API picture, starting with the SDLC and continuing through API inventory tracking and monitoring of APIs at runtime. An organization that pursues these best practices is well positioned to have a strong API security posture.