Resource Data

How a Broken Object-Level Permission Vulnerability Exposed Sensitive Data: API Security Report

To reduce the chances of being the next security incident hot topic, many organizations are taking steps to ensure that their APIs are not vulnerable to exposure of personally identifiable information (PII). This blog describes the discovery of a broken object-level authorization vulnerability (OWASP1 API) by the CQ Prime Threat Research Team that could be used to exfiltrate customer data.

It is 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 not only harm an individual’s credit and inflict damage that takes years to repair, but negatively impact an organization’s reputation and brand.

  • Data from the Federal Trade Commission (FTC) shows that 343,625 fraud reports related to COVID-19 and government stimulus payments were filed between 2020 and 2022.
  • The rapid shift to online shopping has its fair share of benefits, but the resulting increase in cardless transactions (CNP), which accounts for all debit transactions, has led to an increase in CNP fraud.
  • The advent of new, less-supervised 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% increase in the number of companies experiencing data breaches. These violations are one of the main sources of identity theft.

APIs facilitate access to PII

Whether it’s our favorite purchases, money management, food delivery, the ridesharing app or the new cars we drive, the tablets and mobile devices we use, or our home appliances, APIs are at the heart of everything digital. The rapid adoption of APIs has been followed by an equivalent growth in cyber threats, as seen in security incidents at Peloton, ClubHouse, John Deere and more at Optus and Dialog. The same features that developers love in APIs – flexibility, speed, ease of use – are also loved by attackers who find coding errors to exploit, or use bots to attack perfectly coded APIs, or a combination of the of them. Recently, the CQ Prime Threat research team conducted a customer engagement where the team was tasked with uncovering any security weaknesses in the API. The result was the discovery of a BOLA (Broken Object Level Authorization) vulnerability and exploited it to obtain PII data from the organization’s clients. The OWASP API Security Project has defined a BOLA vulnerability as OWASP API Security Top 10 API1. OWASP mentions that API1 involves API vulnerabilities in a situation where APIs will tend to expose endpoints that handle object identifiers, creating a surface-level access control issue. ‘offensive. OWASP states that API security mitigation must involve object-level permission checks in every function that accesses a data source using input from a user. to help secure the API.

Discover API security vulnerabilities

Following the same process an attacker would perform, the engagement began with reconnaissance of the API attack surface to uncover potential API vulnerabilities. Using Burp Suite, a tool for performing web application security testing, the team scanned the entire site by collecting all GET and POST requests made from a web browser and found vulnerabilities. New customer accounts were created, registration forms and password resets performed in an effort to uncover 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 an “email” parameter and value, which in this case was also used as an identifier customer. The answer to this request was quite simple. It returned to the security researcher all the account details associated with the email parameter value (as shown in the image below).

Image 1: POST request response shows redacted account details

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

Leverage an API to access PII

A BOLA vulnerability allows an attacker to gain unauthorized access to resources such as a server containing PII. When an API accesses objects directly, using user-provided input, attackers can manipulate the request to access and potentially steal PII. To test for the presence of a BOLA vulnerability, the researcher tried to change the “email” parameter of the initial request to other accounts created for testing purposes, but in response no data was returned because a cross-site request forgery (CSRF) token has been assigned to the customer account and with that same CSRF token they cannot access any other account. A CSRF token is a value generated by the server with which a web application communicates, proving that a user and the web application they are using are sending a legitimate request from a server-generated form or link . 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 made with the user’s consent.

The security researcher then tried to change the CSRF token with a CSRF token consisting of any random value instead of a true value, to check if CSRF tokens are correctly implemented or if any random value is accepted. Unfortunately, this workaround did not work. The security researcher then completely removed the CSRF token from the request and this approach led them to request data from the server by manipulating the “email” parameter. The security researcher was able to request any user’s data, including PII information such as customer name, profile picture URL, username, phone number, role, and first name and the name. To recap, by simply removing a required parameter from the query, we were able to retrieve data without any authentication. Repeated testing has confirmed that the steps outlined above could potentially lead to unauthorized access to PII or other data.

Best practices for API security to eliminate BOLA vulnerabilities

BOLA-related vulnerabilities are usually a combination of API design and coding errors. API owners should ensure developers and security teams have a full understanding of the desired functionality. This helps ensure that secure coding practices are followed and validated through quality assurance and testing. Additional recommendations include:

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

How Cequence Helps Mitigate BOLA Related Attacks

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

To help uncover data exposure errors, BOLA-related or not, API Sentinel provides a Sensitive Data Exposure Dashboard to quickly identify and remediate APIs and endpoints using sensitive data based on predefined data (such as credit card and social security numbers, Stacktrace codes) and customizable. data models. Context-aware sensitive data detection using a natural language processing (NLP) machine learning technique complements predefined patterns and reduces false positives by enabling teams to find sensitive data exposure at using contextual cues. Results are displayed graphically in a dashboard for fingertip access to details such as API source or response codes leaking data, pattern found, and subnet IP address details. underlying. Notifications can be sent to development teams for quick remediation using predefined alerts for tools like Slack, PagerDuty, or via email.

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

The post How a broken object-level permission vulnerability exposed sensitive data: API security report appeared first on Cequence Security.

*** This is a syndicated blog from Cequence Security’s Security Bloggers Network written by Parth Shukla. Read the original post at: https://www.cequence.ai/blog/cq-prime-threat-research/how-a-broken-object-level-authorization-vulnerability-exposed-sensitive-data-api-security- report/