How BOLA Vulnerabilities Can Expose Sensitive Data: API Security Report

New threat research for API security, this blog walks through the discovery of a Broken Object Level Authorization or BOLA vulnerability (OWASP API1) by the CQ Prime Threat Research Team that could be used to exfiltrate sensitive (customer) data.

It’s well known that attackers can use stolen PII to apply for credit card accounts, government benefits, and loans in the victim’s name. This identity theft can damage not only an individual’s credit and inflict harm that takes years to undo, but negatively impact an organization’s reputation and brand.

• Data from the Federal Trade Commission (FTC) show 343,625 fraud reports related to COVID-19 and government stimulus payments were filed between 2020 to 2022.
• The rapid move to online shopping has its fair share of benefits, but the resulting increase in card-not-present (CNP) transactions, which account of all debit transactions, has led to a surge in CNP fraud.
• The advent of new, less monitored marketplace platforms from food delivery platforms to social networking sites to dating apps have been popping up everywhere — making them easy targets for identity thieves.
• According to a report by the US-based Identity Theft Resource Center (ITRC), the first nine months of 2021 saw a 17% rise in the number of businesses experiencing data breaches. These breaches are one of the prime sources of identity theft.

APIs Facilitate PII Access

Whether it’s our favorite shopping, financial management, food delivery, ridesharing application, or the new cars we drive, the tablets and mobile devices we use, or our home appliances, APIs are the heart of all things digital. The rapid adoption of APIs has been followed by an equivalent growth in cyber threats as seen in the security incidents at Peloton, ClubHouse, John Deere and more at Optus and Dialog. The same characteristics that developers love about APIs – flexibility, speed, ease of use – are also loved by attackers who either find coding errors to exploit, or use bots to attack perfectly coded APIs, or a combination of both. Recently, the CQ Prime Threat Research Team performed a customer engagement where the team was directed to uncover any API security weaknesses. The result was the discovery of a Broken Object Level Authorization (BOLA) vulnerability and exploited it to obtain the PII data of the organization’s customers. The OWASP API Security Project has defined a BOLA vulnerability as OWASP API Security Top 10 API1. OWASP mentions that API1 involves APIs vulnerabilities in a situation where APIs will tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. OWASP states that API security mitigation should involve object level authorization checks in every function that accesses a data source using an input from a user to help secure the API.

Uncovering API Security Weaknesses

Following the same process an attacker would execute, the engagement began with API attack surface reconnaissance to uncover potential API vulnerabilities. Using Burp Suite, a tool for performing security testing of web applications, the team analyzed the entire site collecting all the GET and POST requests made from a web browser and find vulnerabilities. New customer accounts were created, registration forms and password resets executed with the goal of uncovering any business logic errors.

Analysis of the Burp Suite HTTP History tab showed that a POST request made to the server during a new account login exposed a parameter “email” and the value, which in this case, was also used as the customer ID. The response to this request was quite simple. It returned to the security researcher all the details of the account associated with the value of the email parameter (as shown in the image below).

Image 1: Response to a POST request displays redacted details of an account

This behavior confirmed that an API residing on one of the organization’s servers, or endpoint was exposing sensitive data as a response, and with only one parameter in the request, there might be a possibility of a BOLA vulnerability (OWASP API1), as well as the risk of Excessive Data Exposure (OWASP API3).

Exploiting an API to Access PII

A BOLA vulnerability allows an attacker to gain unauthorized access to resources such as a server that contains PII. When an API directly accesses objects, using user-supplied input, attackers can manipulate the request to access and potentially steal PII. To test for the presence of a BOLA vulnerability, the researcher tried changing the “email” parameter from the initial request to other accounts that were created for testing purposes but in response, no data was returned because a Cross-Site Request Forgery (CSRF) token was allocated to the customer account and with that same CSRF token, they cannot access another account. A CSRF token is a value generated by the server that a web application is communicating with, proving that a user, and the web application they’re using is sending a legitimate request from a form or a link generated by the server. The CSRF token is a secure random token that is used to prevent CSRF attacks by ensuring that data requests made by a user are performed with the user’s consent.

The security researcher then tried changing the CSRF Token with a CSRF token made up of any random value instead of a true value, to check if CSRF tokens are implemented properly or any random value is accepted. Unfortunately, this bypass didn’t work. The security researcher then removed the CSRF token completely from the request and this approach them to request data from the server by manipulating the “email” parameter. The security researcher was able to request the data for any user including PII Information such as customer name, profile picture URL, username, phone number, role, and first and last name. To recap, just by removing a required parameter from the request, we were able to fetch data without any authentication. Repeated testing confirmed that the steps outlined above could potentially lead to the unauthorized access of PII or other data.

Best Practices for API Security to Eliminate BOLA Vulnerabilities

BOLA related vulnerabilities are typically a combination of API design and coding errors. API owners must make sure developers and security teams have a full understanding of the desired functionality. This helps to ensure that secure coding practices are followed and validated by QA and testing. Additional recommendations include:

• Tight access control checks on every capability to confirm the user is authorized (the A in BOLA) to access and/or manipulate a requested object.
• Validate any parameters that are sent to the server to access information can help mitigate BOLA attacks.
• Ensuring that CSRF tokens are not transmitted using cookies will help mitigate CSRF vulnerabilities because without a token, an attacker cannot create valid requests to the backend server.
• A CSRF token should be created and saved server-side as part of the user’s session data.
• The server-side application should be designed to check that the token included in the request matches the value that was saved in the user’s session when a later request is received that must be validated. Regardless of the HTTP method or the request’s content type, this validation is required. Similar to when an invalid token is present, the request should be refused if it contains no token at all.

How Cequence Helps Mitigate BOLA-related Attacks

Cequence Security can help organizations uncover and remediate BOLA-related threats with a market-defining Unified API Protection solution that goes beyond API security approaches that may focus solely on web application security or application security testing that are each only one aspect of the API protection journey. Customers can use API Spyder, and API Sentinel to efficiently discover and mitigate these types of API vulnerabilities. API Spyder will discover all external-facing APIs, providing an attacker’s view of external resources. API Sentinel creates an up-to-date API inventory and assesses risks for remediation to eliminate coding errors that can lead to data loss and business disruption.

To help uncover data exposure errors, BOLA-related or otherwise, API Sentinel provides a Sensitive Data Exposure dashboard to quickly identify and remediate APIs and endpoints using sensitive data based on predefined (such as credit card and social security numbers, Stacktrace codes) and customizable data patterns. Context-aware sensitive data detection using a Natural Language Processing (NLP) machine learning technique complements predefined patterns and reduces false positives by allowing teams to find sensitive data exposure using contextual clues. The results are graphically displayed in a dashboard for fingertip access to details such as the API source or response codes leaking the data, the pattern found, and the underlying IP address details. Notifications can be sent to development teams for rapid remediation using predefined alerts for tools such as Slack, PagerDuty, or email.

To protect your APIs and reduce the risk of unauthorized PII access and damage to your organization’s reputation, schedule a Cequence Security API security assessment here.