Description

The API allows authenticated users to access sensitive data by exploiting the use of predictable identifiers. Attackers can leverage this by guessing valid identifiers and then exfiltrating sensitive data after they gain access to a valid user account.

What are considered sensitive data?

Sensitive data is information that, if inadvertently disclosed, could have significant consequences for the data subject. Sensitive data can encompass a wide range of information, including:

• Personally identifiable information (PII), including email, email address, religion or place of residence.
• Financial information, which includes credit cards or bank account numbers.
• Health information, covering medical records or insurance information.
• Government information, which includes social security information or other government related data.
• Proprietary information, which includes secrets or intellectual property (IP),

What are predictable identifiers?

Predictable identifiers pose a security vulnerability in web attacks because they allow attackers to guess or manipulate these identifiers to gain unauthorized access to or control over a resource. For example, if an endpoint is designed to answer to:

• GET api/v1/user?id=1
• GET api/v1/user?id=2
• GET api/v1/user?id=3

An attacker can infer that user IDs are sequential, and can be brute-forced.

Rationale

This finding works by identifying an API that:

• Accepts a numeric user ID parameter within a limited positive integer range.
• Replies with or accepts requests containing personally identifiable information (PII).

Remediation

• Make sure you enforce authorization to resources so that only authorized users can perform the action (AuthZ). Consider the different patterns that are usually followed such as:
  • Role-Based Access Control (RBAC), which is a model that grants resource access to users based on their assigned role. For example, users with the role ADMIN can access the app administrator panel.
  • Attribute-Based Access Control (ABAC), instead relies on attributes of the user to evaluate, this is a more generic case of the previous method since the role can be thought of as an attribute.
• Validate that the ID isn’t guessable, or that it can’t be used to tamper with data. You can use universally unique identifiers (UUIDs) which is a 128-bit number represented as a 36-character string unlikely to be guessed or brute-forced.

JAVA example:

import java.util.UUID;

public class User {
    private String userId;

    public User() {
        this.userId = UUID.randomUUID().toString();
    }

}

• Set up rate-limiting using a detection rule on this API.

References