Response Manipulation FTW: Understanding and Exploiting Response Manipulation

By CdwL852P

This article explores what response manipulation is, how it arises, how it can be exploited to cause other bugs such as Account Takeover (ATO), Elevation of Privileges (EoP), and business logic flaws. Also, it discusses the security best practices to mitigate these risks.

Response manipulation is a type of application security vulnerability that occurs when an attacker modifies the server’s response to a client request before reaching a browser or an Application. This is mostly carried out by modifying data using a proxy interceptor.

Response manipulation exploits the trust relationship between the client and the server. By manipulating server responses, an attacker can deceive the application client into believing that the server has authorized certain actions or provided specific data. This deception can lead to significant security breaches.

Response manipulation arises due to a client-side validation issue where developers rely heavily on response codes and messages to control the flow of the application. This vulnerability is rampant in multi-step authentication processes, such as OTP and 2FA, where the application uses server responses to determine the next step. Response manipulation in JSON and GraphQL endpoints not only undermines authentication mechanisms like OTP and 2FA but can also lead to more severe security vulnerabilities such as Elevation of Privileges (EoP) and Business Logic Flaws. These exploits occur when attackers intercept and modify server responses to escalate their privileges or manipulate application workflows.

Here’s a detailed explanation of how response manipulation can be exploited, with realistic examples.

Developers often rely on the server’s responses to manage the application’s logic and flow. This dependence on response codes (like HTTP status codes) and response messages to validate and guide the application’s behavior can be difficult. When these responses are intercepted and modified by an attacker, the application might proceed with incorrect assumptions, leading to serious security flaws. This reliance on client-side validation rather than robust server-side checks is a fundamental weakness that attackers exploit.

① Response Codes

Response codes are standardized codes that indicate the result of a client request. Common examples include:

· 200 OK: The request was successful.

· 401 Unauthorized: The client must authenticate itself to get the requested response.

Developers often use these response codes to determine the flow of the application. An attempt at login, for instance, would depend on receiving a 200 OK answer in order to access the user’s dashboard; conversely, receiving a 401 Unauthorized response might result in an error message informing the user to try again.

② Response Messages

Response messages provide additional context about the result of a request. These messages might include details about errors or confirmations of successful actions. For instance, an OTP verification might return a message indicating whether the entered OTP is valid or not.

Response manipulation can arise when an attacker sets up an HTTP proxy to intercept and modify JSON responses. This is particularly dangerous in multi-step authentication processes where the application depends on these responses to proceed to the next step.

① Setting Up an HTTP Proxy

Tools like Burp Suite, OWASP ZAP, or Fiddler allow attackers to set up an HTTP proxy that intercepts and modifies HTTP traffic between the client and the server.

② Intercepting the JSON Response

The attacker intercepts the server’s response to the client’s request, typically containing data in JSON format.

③ Modifying the JSON Response

The attacker edits the intercepted JSON response to alter its content, such as changing values or injecting malicious data.

④ Forwarding the Manipulated Response

The proxy forwards the modified response to the client, which processes it as if it were the legitimate server response.

① OTP Bypass

A popular method of authentication called OTP (One-Time Password) verification involves the server sending a special code to the user’s phone number or email address. After entering this OTP, the user can access the program, which first compares the code with the server’s before allowing access. By guaranteeing that only individuals with access to the registered phone number or email address may log in, this is meant to provide an additional degree of protection. However, when an attacker intercepts and manipulates the server’s response during the verification step, they can bypass this security measure.

Original Request:

Original Response:

Manipulated Response:

In this scenario, the attacker changes the “status” field from “failure” to “success” in the OTP verification response. As a result, the application incorrectly proceeds to the next step, thinking the OTP was correct.

② 2FA Bypass

Two-Factor Authentication (2FA) adds an extra layer of security by requiring an additional verification step, often involving a code sent to the user’s phone or email.

Original Request:

Original Response:

Manipulated Response:

Here, the attacker intercepts and modifies the response from the server, changing the status from “failure” to “success.” This bypasses the 2FA check, granting the attacker unauthorized access to the user’s account.

Elevation of Privileges (EoP) is a critical security vulnerability that occurs when an attacker gains higher access rights than initially authorized, allowing them to perform actions beyond their intended capabilities. This exploitation typically arises from flaws in the application’s validation processes, particularly when these processes rely heavily on client-side validation. In the context of JSON and GraphQL endpoints, EoP often involves intercepting and modifying server responses to escalate privileges within the application. For instance, attackers can manipulate responses that determine user roles, changing their role from a standard user to an administrator, thereby gaining unauthorized access to sensitive functionalities or data intended for higher-privilege users.

A common scenario where EoP can occur is within role-based access control (RBAC) systems. These systems use server responses to assign and validate user roles during authentication and authorization processes. Developers may implement logic that checks the user’s role based on the server’s response and grants access accordingly. However, if an attacker intercepts and alters this response, they can deceive the application into assigning a higher role than intended. For example, if a server response initially assigns the role of a ‘user,’ an attacker could modify this response to ‘admin,’ granting themselves access to administrative functions and sensitive information. This manipulation exploits the application’s trust in the server’s response to maintain accurate role assignments.

Example: Role Escalation

In many applications, role assignments are determined by server responses following specific requests. Attackers can manipulate these responses to elevate their role from a standard user to an administrative user, granting them unauthorized access to sensitive functionalities or data.

Original Request:

Original Response:

Manipulated Response:

When an attacker manipulates a server response to change their role from a standard user to an administrator (e.g., modifying “role”: “user” to “role”: “admin”), they exploit the application’s reliance on client-side validation. In such scenarios, the client-side application trusts the authenticity of the response without verifying it server-side. This deception leads the application to incorrectly perceive the attacker as an administrator. Without adequate server-side protections in place to validate user roles and permissions, the attacker gains unauthorized access to administrative functionalities. This can enable them to perform actions such as modifying user accounts, accessing sensitive data, and executing administrative commands, posing significant security risks to the application and its users.

Business Logic Flaws arise from incorrect implementation of business rules and workflows within an application. Response manipulation can exploit these flaws by altering the expected flow of operations or causing unintended actions.

In many web applications, access to certain pages or functionalities is controlled by server responses that determine the user’s permissions. An attacker can manipulate these server responses to gain access to restricted areas of the application. By changing response codes or response messages, the attacker can trick the application into granting access to pages they should not be allowed to view or use.

This manipulation occurs because the application relies on the server’s response to enforce access control. If the server responds with a status code or message indicating that access is denied, the application should prevent the user from accessing the page. However, if an attacker intercepts this response and changes it to indicate that access is granted, the application will proceed as if the user has the necessary permissions. This kind of response manipulation undermines the application’s access control mechanisms, allowing attackers to bypass restrictions and gain unauthorized access.

Original Request:

Original Response:

Manipulated Response:

In this scenario, the attacker changes the “isAuthorised” field from “false” to “true” in the access check response. As a result, if the application does not have server-side validation it incorrectly allows the user to access the restricted admin dashboard.

Security researchers should thoroughly understand the application’s flow and closely inspect every request and response. This diligence is essential to identify instances where the application improperly relies on client-side validation for server responses, enabling them to implement necessary security measures.

Developers must always perform validation on the server side, rather than relying on the client side to determine when an action should be executed. This practice ensures that all critical operations are securely validated and mitigates the risks associated with response manipulation exploits.