Server Side Parameter Pollution in Rest API path parameter

What is Server Side Parameter Pollution?

#

Server-side parameter pollution in a REST API is a type of attack where an attacker manipulates URL path parameters to exploit vulnerabilities in the API. This takes advantage of how the server handles and interprets the parameters provided in the URL path. If the server does not properly validate or sanitize the parameters, an attacker can inject malicious values to alter the intended behavior of the API. This can result in unauthorized access to sensitive resources or performing actions that were not intended by the API’s designers.

How parameters work in API Endpoint?

#

What is path parameter?

#

GET /api/users/{userId}

When a client makes a request to an API endpoint with path parameters, the server’s backend is responsible for extracting and processing those parameters. Here’s how the backend typically handles path parameters in an API:

1. Parsing the URL Path: When a request is received, the server’s routing mechanism parses the URL path to determine which endpoint is being targeted and extracts any path parameters included in the request.
2. Parameter Extraction: Once the endpoint is identified, the backend extracts the values of the path parameters from the URL path. These values are then made available to the server-side code for further processing.
3. Parameter Validation: After extracting the path parameters, the backend may perform validation to ensure that the provided parameter values meet certain criteria or constraints. This validation helps prevent errors and ensures the integrity of the data being processed.
4. Handling the Request: With the path parameters extracted and validated, the server-side code can now handle the request accordingly. This may involve querying a database, performing business logic, or retrieving specific resources based on the provided parameter values.
5. Generating a Response: Once the necessary operations are completed, the backend generates a response containing the requested data or information. This response is then sent back to the client, typically in the form of JSON, XML, or another data format.

How path traversal vulnerability can be used to manipulate params in API Path?

Example API Endpoint:

#

Let’s consider an API endpoint for retrieving information about a specific product. The endpoint URL includes a path parameter {productId} representing the unique identifier of the product.

API Endpoint Definition (Express.js - Node.js):

const express = require('express');
const app = express();

// Define the API endpoint with path parameter
app.get('/api/products/:productId', (req, res) => {
    // Extract the value of the path arameter
    const productId = req.params.productId;

    // Retrieve product information based on productId
    // (This would typically involve querying a database)
    const product = getProductById(productId);

    // Return the product information as JSON response
    res.json(product);
});

// Start the server
app.listen(3000, () => {
    console.log('Server is running on port 3000');
});

// Function to retrieve product information (dummy implementation)
function getProductById(productId) {
    // Dummy product data
    const products = {
        1: { id: 1, name: 'Product A', price: 19.99 },
        2: { id: 2, name: 'Product B', price: 29.99 },
        3: { id: 3, name: 'Product C', price: 39.99 }
    };

    // Return the product corresponding to the productId
    return products[productId] || null;
}

HTTP Requests:

GET Request to Retrieve Product Information:

#

To retrieve information about a specific product (e.g., product with ID 2), the client sends a GET request to the API endpoint with the appropriate path parameter.

GET /api/products/2 HTTP/1.1
Host: example.com

In this HTTP request:

• Method: GET
• Endpoint: /api/products/2
• Host: example.com (replace with the actual host)

The value 2 in the endpoint URL represents the {productId} path parameter, indicating that the client is requesting information about the product with ID 2.

{
"id": 2,
"name": "Product B",
"price": 29.99
}

Response:

Upon receiving the request, the server extracts the value 2 from the path parameter and retrieves the corresponding product information. It then returns the product information as a JSON response.

This JSON response contains the details of the product with ID 2, including its name and price.

How server normalize API path?

#

1. API path normalization refers to the process of simplifying the structure of URL paths used to access API endpoints. This normalization ensures consistency and ease of use for clients interacting with the API. Here’s how servers typically normalize API paths:

2. Removing Redundant or Duplicate Elements: One common normalization step involves removing redundant or duplicate path elements from the URL. This helps simplify the path and ensures that equivalent paths are treated identically. For example, /api/users/123 and /api/users/123/ may refer to the same resource, so the trailing slash is often removed.

3. Handling Case Sensitivity: URL paths are typically case-sensitive, but servers may normalize paths to a consistent case (e.g., lowercase) to avoid confusion and improve compatibility across different platforms.

4. Stripping Query Parameters: During normalization, any query parameters included in the URL may be removed if they are not relevant to the endpoint being accessed. This simplifies the path and ensures that only the necessary information is included.

5. Removing Extra Stuff:

   • Original Path: /api/user/profile?id=123&token=abc
   • Normalized Path: /api/user/profile

6. Making Paths Clear:

   • Original Path: /API/UserData
   • Normalized Path: /api/userdata

7. Figuring Out Relative Locations:

   • Original Path: /api/user/../post
   • Normalized Path: /api/post

8. Ignoring Unnecessary Details:

   • Original Path: /api/user/profile?lang=en
   • Normalized Path: /api/user/profile

9. Making Things Standard:

   • Original Paths: /api/user-info and /API/User-Info
   • Normalized Path: /api/user-info

Server Side Parameter in REST API

#

Server-side parameter pollution in a REST API occurs when an attacker manipulates URL path parameters to exploit vulnerabilities in the API. This type of attack takes advantage of how the server handles and interprets the parameters provided in the URL path.

When a client sends a request to the server with URL path parameters, the server typically processes these parameters to determine the appropriate action to take. However, if the server does not properly validate or sanitize the parameters, an attacker can inject malicious values to alter the intended behavior of the API.

The attack works by injecting path traversal sequences or other malicious input into the URL path parameters. These sequences may include special characters or encoded values designed to manipulate the server’s interpretation of the path. By doing so, the attacker can trick the server into accessing resources or performing actions that were not intended by the API’s designers.

For example, consider an API endpoint for editing user profiles based on usernames. If the API endpoint is vulnerable to parameter pollution, an attacker could inject a path traversal sequence such as “../admin” into the username parameter. This could potentially grant the attacker unauthorized access to administrative functions or sensitive user data.

The attack works because the server fails to properly validate or sanitize the URL path parameters, allowing the attacker to manipulate the path in unexpected ways. Additionally, if the server normalizes the path without proper validation, it may inadvertently resolve the malicious input to a different location or resource, further exacerbating the impact of the attack.

Overall, server-side parameter pollution exploits weaknesses in the server’s handling of URL path parameters, allowing attackers to manipulate the API’s behavior for malicious purposes.

Server Side Parameter Example:

#

Suppose we have an API endpoint /api/users/{username} that retrieves user information based on the provided username.

1. Client Sends Request: The client sends a request to retrieve user information for a specific username.

   HTTP Request:

   GET /api/users/peter HTTP/1.1
   Host: example.com
   

2. Server Processes Request: The server receives the request and processes it to retrieve user information for the username “peter”.

Exploiting Path Traversal:

• When the server processes the manipulated request, it interprets the traversal sequences (../) in the username parameter.
• The traversal sequences cause the server to navigate up the directory hierarchy from the user-specific directory (peter) towards the root directory (/) or other sensitive directories.
• In this example, the attacker aims to navigate to the “admin” directory or access resources intended for administrative users.

1. Attack Attempt: An attacker attempts to manipulate the URL path parameter to access sensitive information or perform unauthorized actions.

HTTP Request (Attack):

GET /api/users/peter/../admin HTTP/1.1
Host: example.com

2. Server-Side Handling: The server may incorrectly interpret the manipulated URL path parameter, potentially leading to unintended consequences.
   • If the server does not properly validate or sanitize the parameter, it may resolve the path to access sensitive resources such as administrative functions.
   • If the server normalizes the path without proper validation, it may inadvertently resolve the manipulated input to a different location or resource.
3. Response: The server responds to the request, potentially disclosing sensitive information or performing unintended actions based on the manipulated parameter.

HTTP Response:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "username": "admin",
    "role": "administrator",
    "email": "admin@example.com"
}

Practical Demonstration

#

Watch this video to understand the exploitation of SSPP in Rest API.

Discovering and learning about this vulnerability was enjoyable. I hope you had a good time too. Thanks for reading along.