Modern software development has become reliant on APIs (Application Programming Interfaces), which allow software applications to communicate with one another effortlessly. Security issues are ever-changing along with the digital landscape.
Internet connectivity is not always possible for internal APIs found in certain systems. User input embedded in a server-side request to an internal API by a website without proper encoding is known as server-side parameter pollution.
It follows that an attacker could be able to inject or modify parameters, giving them the ability to do things like override pre-existing options.
- Get unapproved data access
- Change the way the application behaves.
We are able to view the results on our screen, however the code only operates on the server-side when any parameter is tampered with. A black box process occurs in between.
Server-Side Parameter Pollution in the query string
The term Query String is commonly used to refer to the part between the “?” and the end of the URI as defined in the RFC 3986, it is a series of field value pairs. Pairs are separated by “&” or “;” and the usage of semicolon in order to avoid escaping. RFC 2396 defines two classes of characters:
- Unreserved: a-z, A-Z, 0–9 and _.! ~ * ‘ ( )
- Reserved: ; / ? : @ & = + $ ,
Multiple mechanisms can lead to server-side parameter pollution in the query string vulnerabilities. To gain a better understanding, let us examine each kind of vulnerability and offer instances.
- Information Disclosure: IDOR happens when a hacker gains direct access to or control over resources by changing request parameters like filenames or IDs. A user may examine their own profile in a web application by going to /profile?id=123. In order to examine the profile of another user, an attacker modifies the ID parameter to id=124.
- Injections Attacks: Malicious code or data is injected into an application through injection attacks, which can result in unexpected behaviour or exploitation. An attacker can use example SQL injection to introduce SQL queries into input fields. For example, you can change the SQL query to extract all user data by changing a parameter from?username=user to?username=user’ OR ‘1’=’1′.
- Denial of Service Attacks: The goal of denial-of-service (DoS) assaults is to stop a service from being available by flooding it with so many requests that it becomes unusable. As an illustration An attacker uses up server resources by sending a lot of requests with overly long parameter values, which slows down or crashes the service.
- XSS Attacks: Malicious JavaScript code is injected into server-side requests by attackers via SSPP, especially in query parameters. A malicious script, such as <script>alert(‘XSS’)</script>, is injected into a URL by an attacker by manipulating a query parameter, such as name. Users’ browsers run the script when this corrupted input is reflected back to them, which can result in unwanted activities like stealing session cookies or sending users to dangerous websites.
- XML External Entity (XXE) Attacks: An attacker uses weaknesses in XML parsers to carry out server-side request forgery (SSRF), reveal private information, or run arbitrary code. An external entity reference that points to a private file on the server is added by an attacker through manipulation of XML input parameters. Sensitive information, including configuration files and database credentials, may end up public.
- Parameter Tampering: manipulates parameters in order to change how an application behaves or gain access to unapproved features. To get around permission restrictions or gain access to administrative functionality meant only for privileged users, an attacker modifies the query parameters. Elevated privileges could be granted, for example, by changing a parameter value from isAdmin=false to isAdmin=true.
- Remote File Inclusion(RFI): The attacker uses SSPP to incorporate and run files from a malicious server remotely, which might result in the execution of arbitrary code or unapproved access to data. In order to incorporate URLs pointing to malicious scripts hosted on distant servers, an attacker alters the parameters. After the scripts are run on the server, the attacker can take over the programme and access private information.
Webserver Response to Query String
Internal API interprets two name parameters. Depending on how the application handles the second parameter, this could have an effect. This differs depending on the web technology. As an illustration:
Here are some of the Back-end Server that Support the First Occurrence only:
- JSP, Servlet/Apache Tomcat
- JSP, Servlet/Oracle Application Server
- JSP, Servlet/Jetty
- IBM HTTP Server
- mod_perl, libapreq2/Apache
- Perl CGI/Apache
- mod_wsgi (Python)/Apache
Back-end Server that Supports the Second Occurrence only:
- PHP/Apache
- PHP/Zeus
- IBM Lotus Domino
Back-end Server that Supports All Occurrences:
- NET/IIS
- ASP/IIS
- Python/Zope
An attacker may be able to manipulate server-side URL path parameters to exploit the API. To test for this vulnerability, add path traversal sequences to modify parameters and observe how the application responds.
Exploitation Scenario
While parameter pollution is not a vulnerability in and of itself, it might be linked to other vulnerabilities. It can be applied to application behaviour chaining and URL rewriting. The impact of parameter pollution is contingent upon the operation of the web application or its surroundings. Both client-side and server-side components are impacted by parameter pollution. To test for server-side parameter pollution in the query string, place query syntax characters like #, &, and = in your input and observe how the application responds.
In a fictitious user search situation, the following condensed code snippets serve as an elementary example of server-side parameter pollution:
Case 1
Think of a vulnerable programme that lets you look up other users by using their username. Your browser sends the following request when you look for a user:
GET /userSearch?name=allen&back=/home
The server makes the following request to an internal API in order to obtain user information:
GET /users/search?name=allen&publicProfile=true
Case 2
You can try to terminate the server-side request by using a # character encoded in the URL. You might perhaps include a string after the # character to aid in your interpretation of the response.
For example, you may modify the query string to the following:
GET /userSearch?name=allen%23alan&back=/home
The front end will attempt to connect to the given URL:
GET /users/search?name=allen#alan&publicProfile=true
Case 3
You can try adding a second argument to the server-side request, use a & character encoded with the URL.
For example, you could modify the query string to the following:
GET /userSearch?name=allen%26alan=xyz&back=/home
This results in the following server-side request to the internal API:
GET /users/search?name=allen&alan=xyz&publicProfile=true
As you can see, we are injecting a query string to cause the server-side request to accept the parameter. The publicProfile=true result indicates that the API has completed the request with a 200 OK response by looking for hints in the answer regarding whether the query has been shortened.
Preventing server-side parameter pollution
To prevent server-side parameter pollution, use an allowlist to define characters that don’t need encoding, and make sure all other user input is encoded before it’s included in a server-side request. You should also make sure that all input adheres to the expected format and structure. Make sure to perform an extensive and proper input validation. All user-supplied data, which is reflected in the HTML source code of the HTTP response, should be encoded according to the context in which they are reflected.
- Validate and Sanitise Input: The first line of defence against SSPP assaults is appropriate input validation. Verify that the entering parameter values follow the anticipated format by validating them. Clean up the input as well to eliminate any potentially dangerous characters or sequences that might be utilised in injection attacks.
- Handle Each Parameter Separately: Handle every parameter as a distinct item and handle them separately. Refrain from assuming anything regarding the dependency or order of the parameters. Regardless of where a parameter appears in the request, handle it according to its intended use.
- Apply parameter integrity checks: On the server side, confirm the accuracy and validity of parameter values. Make sure the received data fulfil certain requirements or are within expected limitations by doing checks like pattern matching or range validation.
- Using Proper Input Parsing: Create a parameter parsing logic for your application that allows it to handle input safely and securely. Parsing methods may differ depending on the type of parameter. To avoid unexpected behaviour or manipulation, apply the proper parsing techniques that are unique to each parameter.
- Utilize Whitelisting: List all acceptable values for each parameter on a whitelist. Deal with or reject any parameters whose values are not on the pre-established whitelist. The likelihood of HPP assaults can be greatly decreased by implementing a whitelist strategy.
To sum up, web applications must be kept safe by avoiding server-side parameter pollution. Whitelisting is one method we utilise to prevent potential threats by carefully reviewing and managing user input. A safer online environment can be achieved by being watchful and implementing security procedures, which also serve to keep our apps reliable and impervious to hacking.
