Unauthenticated route write using predictable IDs
Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel,
n'hésitez pas à nous contacter.
Description
The API accepts predictable identifiers (IDs) without any authentication mechanism. Attackers can leverage this by guessing valid identifiers, to steal sensitive information or perform unauthorized actions.
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:
- 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), which 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