Unauthenticated route returns sensitive data using predictable IDs

Description

The API allows unauthenticated users to access sensitive data by exploiting the use of predictable identifiers (IDs). Attackers can leverage this by guessing valid identifiers and then exfiltrating sensitive data.

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 might infer that user IDs are sequential, and can be brute-forced.

Rationale

This finding works by identifying an API that:

  • Lacks an authentication mechanism.
  • Accepts a numeric user ID parameter within a limited positive integer range.
  • Replies with or accepts requests containing sensitive data.

Remediation

  • Validate that the code isn’t expecting the user to be authenticated to have access to this resource (AuthN). In case this API it is in fact authenticated, ensure your code is instrumented correctly. Datadog auto-instruments many event types, review your instrumented business logic events.
  • 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();
    }

}
  • 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.
  • Set up rate-limiting using a detection rule on this API.

References

ReferenceDescription
OWASP - Authentication Cheat SheetAuthentication Cheat Sheet: guidance on the best practices in authentication area.
OWASP - Authorization Cheat SheetAuthorization Cheat Sheet: guidance on the best practices to implement access controls.