Parameter tampering is a web-based attack targeting the application business logic in order to perform or achieve a specific malicious task/attack different from the intended behaviour of the web application.
The attack involves modifying application data, such as user credentials and permissions, price and quantity of products, etc, by manipulating the parameters that are being exchanged between the client and the application’s server. Parameter tampering is considered to be simple but quite effective.
Parameter tampering can often be done with:
URL query strings
Parameter tampering can be performed in several ways resulting in data disclosure to server-side attacks.
A cookie is a small piece of information usually created by the web server and stored in the web browser. They are used as a convenient mechanism to store user preferences and other data including session tokens.
The cookies can be modified by the client and sent to the server with URL requests. Therefore any malicious user can take advantage of this to modify cookie content.
The attacker can modify the cookie to:
The form field manipulation occurs when an attacker tries to alter the behaviour of a form by illegitimately changing the data sent to the web server. When a user makes selections on an HTML page, they are usually stored as form field values and sent to the web application. These values can be pre-selected using combo box, checkbox, radio button, etc, free text or hidden. All of these values can be manipulated by an attacker by viewing the source code of the web application.
Hidden fields are parameters invisible to the end-user, which includes data that cannot be seen or modified by the users when submitting the form, and it is normally used to provide status information to the web application.
Suppose a form was used for making a purchase. Here’s an example that includes a “hidden” field:
An attacker can change this value to 70.00 and it will cause the web application to charge according to the new amount as shown below.
When the URL passes sensitive values through parameters, the attacker can tamper this query string and perform malicious actions.
For example, suppose a web page allows an authenticated user to select one of his/her accounts from a combo box and then debit the account with a fixed unit amount. The following URL is requested:
The attacker can manipulate this URL to credit a higher amount to another account as shown below:
The referer header, which is included in the HTTP request header, normally contains the URL of the web page from which the request originated.
Some websites use this referer header in order to make sure that the request originated from a page generated by them and also to identify where people are visiting them from. These data can be used for analytics, logging, or optimized caching.
But sometimes attackers will be able to modify the referer header to look like it came from the original site.
Assuming a string consisting of alphanumeric characters which may be a username, such as “John Smith”, is submitted in the request, the HTTP response including this cookie might take the following form:
If an attacker submits a malicious string, such as “John Hacker\r\nHTTP/1.1 200 OK\r\n…”, then the HTTP response would be split into two responses of the following form:
The attacker will have complete control over the second response and can be constructed with any header and body content desired. The ability of an attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including cross-user defacement, web and browser cache poisoning, cross-site scripting, and page hijacking, etc.
Parameter tampering can be prevented by the following means:
Use a whitelist format for the application’s inputs.
Use web application firewalls for utmost protection.
Encrypt the session cookies to prevent tampering.
If the cookie originated from the client-side, such as a referrer it should not be used to make any security decisions.
Avoid including parameters into the query string.