HTTP parameter pollution

Need

Prevention of HTTP parameter pollution

Context

• Usage of TypeScript for statically typed JavaScript development
• Usage of Express for building web applications and APIs

Description

Non compliant code

import express from 'express';

const app = express();

app.get('/search', (req, res) => {
  const query = req.query.q;
  res.send(`Searching for: ${query}`);
});

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

The vulnerability in the given code is HTTP parameter pollution. This vulnerability occurs when the application allows extra parameters to be injected into the HTTP communication protocol. In this case, the vulnerability arises from the fact that the code does not validate the number of parameters received from the client.

In the code, the Express framework is used to create a server. The server listens for GET requests on the '/search' endpoint. When a GET request is made to this endpoint, the code retrieves the value of the 'q' parameter from the request query using req.query.q. It then sends a response back to the client with the message "Searching for: {query}".

However, the code does not validate the number of parameters received. This means that an attacker can inject additional parameters into the request, causing unexpected behavior on the server. For example, an attacker could send a request with multiple 'q' parameters, each with a different value. This could lead to the server processing the request incorrectly or producing unexpected results.

The impact of this vulnerability is that the application may read and process malicious parameters, leading to incorrect behavior. It can also cause unexpected behaviors on the application, potentially exposing sensitive information or allowing unauthorized access.

To fix this vulnerability, the code should implement validations to ensure that the number of received parameters is equal to the expected parameters on the server. This can be done by checking the length of the request query object and only processing the expected parameters.

Steps

• Validate the number of parameters received in the request
• If the number of parameters is greater than the expected number, handle the error or ignore the extra parameters
• If the number of parameters is less than the expected number, handle the error or send an appropriate response
• Ensure that the expected parameters are properly validated and sanitized to prevent any potential security vulnerabilities

Compliant code

import express from 'express';

const app = express();

app.get('/search', (req, res) => {
  const expectedParams = ['q'];
  const receivedParams = Object.keys(req.query);

  if (receivedParams.length > expectedParams.length) {
    // Handle error or ignore extra parameters
    res.status(400).send('Too many parameters');
    return;
  }

  if (receivedParams.length < expectedParams.length) {
    // Handle error or send appropriate response
    res.status(400).send('Missing parameters');
    return;
  }

  const query = req.query.q;
  // Validate and sanitize the query parameter if necessary

  res.send(`Searching for: ${query}`);
});

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

The fixed code is written in TypeScript and uses the Express framework to handle HTTP requests. It addresses the vulnerability by implementing validations to ensure that the quantity of received parameters is equal to the expected parameters on the server.

Here's a breakdown of the code:

1. The code imports the necessary modules, including the Express framework.

2. An instance of the Express application is created.

3. The code defines a route for the '/search' endpoint using the app.get() method. This route handles GET requests to the '/search' URL.

4. Inside the route handler function, two arrays are defined: expectedParams and receivedParams. expectedParams contains the names of the parameters that the server expects to receive, while receivedParams is an array of the actual parameter names received in the request query.

5. The code checks if the number of received parameters is greater than the number of expected parameters. If so, it sends a 400 Bad Request response to the client with an error message indicating that there are too many parameters. This helps to prevent the server from processing unexpected or potentially malicious parameters.

6. Next, the code checks if the number of received parameters is less than the number of expected parameters. If so, it sends a 400 Bad Request response to the client with an error message indicating that there are missing parameters. This ensures that all the required parameters are provided in the request.

7. If the number of received parameters matches the number of expected parameters, the code retrieves the value of the 'q' parameter from the request query. This value represents the search query.

8. At this point, you can perform any necessary validation and sanitization on the query parameter. This step helps to ensure that the query is safe and does not contain any malicious content.

9. Finally, the code sends a response to the client with a message indicating the search query.

10. The code also starts the Express server and listens on port 3000 for incoming requests.

By implementing these validations, the fixed code ensures that only the expected parameters are processed, preventing unexpected behavior and potential security issues caused by HTTP parameter pollution.

References

• 121.HTTP parameter pollution