crAPI: Excessive Data Exposure

Amit Dubey

August 30, 2022 · 2 min read

It’s been a while since I’ve written a blog post. Today, I will talk about Excessive Data Exposure and how to identify it using crAPI.

Excessive data exposure is when an API exposes more data than necessary. This could happen for several reasons, but the most common is that the API was not designed with security in mind. Excessive data exposure could lead to significant security flaws, such as data leakage and information disclosure. While the backend developer would expect its client to sanitize this information before presenting it to the user, even if the client performs its job correctly, the information might still be exposed during transmission and abused by a malicious attacker.

The “leaky bucket” vulnerability in Amazon’s S3 storage service is a well-known example of excessive data disclosure. This weakness enabled anyone, regardless of security settings, to access any file stored in an S3 bucket. This resulted in a significant data breach, exposing sensitive information such as passwords and credit card details.

Attack Scenario 1:

crAPI is a vehicle management application that allows users to purchase replacement parts and accessories for their automobiles. In addition, it has a community forum page on which users can publish short blog posts. After that, all of the other users on the platform can access the blog post and contribute their thoughts to the discussion it contains. On the other hand, these blog post discloses just the user ID of the person who wrote the article and the person who commented on that blog post.

1. Authenticate to the application as “Victim Two” and Navigate to the “Community” page of the application.

2. Click on “+ New Post” and add a post.

3. Now Navigate back to the Forum page and capture the request using a proxy tool such as (ZAP or Burp).

4. Note that, although the application does not display another user’s email, the API response does.

5. An attacker then uses these emails to exploit the weakness further.

Attack Scenario 2:

The profile management page of crAPI includes a module for uploading personal videos. The user can also modify the video’s title and add a new video. Upon analyzing the video upload request, it was discovered that the application’s response exposed the video conversion encoding codec. This information was then used to craft a Mass assignment vulnerability in video title edit request, thus escalating the vulnerability to Command Injection severity.

1. Authenticate to the application as a user and Navigate to the “Profile” page.

2.Note that a user can upload any personal video to the application.

3. Now, use a proxy tool to capture the video upload request. Look at the “coversion_params” parameter in the response, which leaks the conversion codec.

4. Using this information, the attacker could craft a request and exploit the application’s Mass Assignment vulnerability, which could escalate to Command Injection.

Remediation:

Never trust the client to filter sensitive information.
Check the API responses to ensure they include only accurate data.
Before exposing a new API endpoint, backend developers should always ask themselves, “Who is the consumer of the data?.”
Categorize sensitive and personally identifiable information (PII) that your application stores and uses, and evaluate any API calls that return such information to determine whether these pose a security risk.
As an added layer of protection, provide a schema-based response validation method. This mechanism defines and enforces data provided by all API methods, including error data.

You no longer need to worry. Levo has already found PII and tested for API schema conformity for many businesses.