Server-Side Parameter Pollution (SSPP) Through Query Strings

YouTube

Index:

1. Introduction

2. What is Server-Side Parameter Pollution

3. Understanding the Query String in an API Request

4. Example

5. Injecting Invalid Characters

6. Quick Reference

7. Backend Code Example

   
   
   
   

Introduction: Exploring Server-Side Parameter Pollution in Query Strings

There are three common ways that an API endpoint accepts parameters:

• Query string (after the question mark in the URL),

  1. 

• JSON body (passed in the body of the request),

  1. 

• Path parameters (embedded directly within the URL)

  1. 
     

     

     
     

Today, we’re focusing on what happens if a server fails to validate the inputs within the query string of an API request. Specifically, we’ll explore how server-side parameter pollution (SSPP) can impact APIs that rely on query string parameters.

If you’re unfamiliar with server-side parameter pollution,

What Is Server-Side Parameter Pollution?

Server-Side Parameter Pollution (SSPP) is a vulnerability that arises when an application does not properly handle duplicate parameters passed in a URL query string. Attackers can manipulate these parameters, often leading to unintended behavior by the server, such as bypassing access controls, modifying data, or even exploiting more critical vulnerabilities.

Understanding Query String Parameters in an API

So, how do query string parameters work in an API? When a client makes a request to an API endpoint with a query string, the server processes it as follows:

1. Parsing the URL: The server reads the URL and identifies the query string (everything after the ?) to figure out which parameters are being sent.

   
   

2. Extracting Parameters: It pulls out the query string parameters and stores them for the server-side code to use.

   
   

3. Validation: Ideally, the server checks that the parameters meet specific criteria—such as data type, length, and allowed values—but if this step isn’t done correctly, it can lead to security issues.
   

4. Handling the Request: The server uses the parameters to execute its business logic (such as querying a database or processing user input) and then returns a response, often in JSON or XML format.

   
   

Example of Server-Side Parameter Pollution via Query Strings

Now that we know the basic flow, let’s take a look at some examples to demonstrate how server-side parameter pollution can occur and how an attacker might exploit it.

How Does It Work?

When you make a request to a web server, parameters are often sent through the URL in the query string. An example URL might look like this:

https://shopwebsite.com/buy?item=shoes&discount=10

In this case, you’re telling the server you want to buy shoes and apply a 10% discount. Now, what happens if we add multiple parameters with the same name?

https://shopwebsite.com/buy?item=shoes&item=hat&discount=50

Here, two item parameters are passed, and this is where SSPP comes into play. The way the server processes multiple parameters can vary, depending on how it’s coded.

Injecting Invalid Parameters

You can attempt to inject a second parameter and or learn more about the application and how it handles a server-side request by adding an URL-encoded & character to the query string.

For example, you could modify the URL like this:

bash

GET /productSearch?item=laptop%26item=computer&return=/shop

This would result in the following server-side request to the internal API:

sql

GET /products/search?item=laptop&item=computer&inStock=true

Analyze the server's response for clues on how the additional parameter is processed. If the response remains unchanged, it could indicate that the parameter was successfully injected but ignored by the application.

• PHP parses the last parameter only. This would result in a search for a computer only.
  

• ASP.NET combines both parameters. This would result in a search for laptop and computer which might result in an Invalid item error message.
  

• Node.js / express parses the first parameter only. This would result in a user search for laptop, giving an unchanged result.

Quick Reference Chart: Server-Side Parameter Pollution (SSPP) in Query Strings

Query String Structure	Example URL	Potential Outcome
Single Parameter	https://shop.com/cart?item=shoes&discount=10	Normal behavior: A 10% discount is applied.
Duplicate Parameters (Same)	https://shop.com/cart?item=shoes&discount=10&discount=50	SSPP risk: Discount might change to 50%, depending on how the server processes it.
Different Values for Same Parameter	https://shop.com/cart?item=shoes&item=hat	SSPP risk: The server might apply only one item (shoes or hat) or both, based on server logic.
Sensitive Parameter Bypassing	https://bank.com/account?user=guest&user=admin	SSPP risk: Possible bypass of access controls, granting access to admin functions.
First Come, First Served	https://shop.com/cart?discount=20&discount=50	Server uses the first discount=20 and ignores the second.
Last Come, First Served	https://shop.com/cart?discount=20&discount=50	Server uses the last discount=50, overwriting the first.
Concatenation	https://shop.com/cart?color=red&color=blue	Server might concatenate values (color=red,blue), causing unexpected behavior.

Backend Code Example

const express = require('express');

const app = express();

app.get('/search', (req, res) => {

    // Get query string parameters

    const query = req.query.query;

    const limit = parseInt(req.query.limit) || 10; // Default limit is 10

    // Process the parameters

    if (query) {

        // Simulate business logic (e.g., querying a database)

        const results = { items: [`Result for ${query}`], limit: limit };

        res.json(results);

    } else {

        res.status(400).json({ error: "No search query provided" });

    }

});

app.listen(3000, () => {

    console.log('Server running on port 3000');

});

BurpSuite Portswigger Lab Example