Parameter Tampering Attack

What is parameter tampering attack?

This cybersecurity vulnerability entails tempering or modifying the parameters associated with the client and server. The critical-most parameters that are generall accessed, via multiple techniques, and are further modified so that a specific data/credential/information is obtained.

Here, the targeted parameter could be anything. It could be the sales data or user credentials. Only web application parameters, stockpiled in URL Query Strings, cookies, HTTP headers, and hidden fields in HTML forms, are used for this attack. Let’s learn about all these in detail.

‍

Examples of parameter tampering

HTTP Header

For those not knowing the meaning of HTTP header, it’s a term referring to the controlled piece of content/information that an HTTP-based request transmits from client to server and a server-side HTTP response delivers to the client. Every HTTP header features a standard ASCII text, a numeric value, and a name.

Here is a sample header for your reference:

Host: www.xplace.org
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14
Referer: http://www.xplace.org/login.php
Content-type: application/x-www-form-urlencoded
Content-length: 86

Most commonly, HTTP headers are consumed by web server software and browsers and often work silently. This is why they aren’t part of API security policy as well, in many cases. 

However, some security-concerned developers decide to monitor received headers. Those who are involved in the job must pay extra attention to the client-side HTTP headers as, if adequate security measures aren’t adopted, client-side HTTP headers could feature corrupted links or codes, inserted by an attacker. 

An attacker has to do extra labor to corrupt an HTTP header as most of the browsers restrict HTTP header access. For HTTP header modification, attackers usually write a customized program, using Perl code, or use any of the available free proxies. Both these options permit HTTP header tampering.

Mitigation 

When it comes to HTTP header protection, client-side HTTP headers are hard to manage when they are created as the referer. The only way to keep the vulnerability odds as low as possible is not to use such headers. 

When it comes to server-side HTTP headers, one can protect them against the vulnerability by using the cryptographic keys. Adding cryptographic keys makes the parameter hard to decode. By all means, HTTP headers should be entertained in the absence of robust security practices. 

‍

URL Query Strings

The URL query string is the query string, attached with the URL, after ?. Basically, whatever text you find in a URL after? is the URL query string.

For example:

https://sample.com/over/here?name=ferret

In this URL, the text after? is name=ferret and is the URL query string. Character-wise, query strings consist of value and parameter and are linked with = sign. In the above example, name and ferret represent parameters and values respectively. 

Now, let’s understand the meaning of URL query string tampering. It's an easy job for a skilled hacker as only a clever introduction of sensitive values via parameters is required. Once this is done, the attacker is successful in tampering with the URL query string and performing malicious actions. 

A simple example, depicting URL query string manipulation, is mentioned below:

http://www.easy.com/sample?visitordata=12345&copydata=1

Using this HTTP request, an admin can export the visitor data of the website. However, an attacker, having ill intentions, can manipulate this query string and export more data or steal it. 

The only thing that s/he has to do is alter the parameter value. 

http://www.easy.com/sample?visitordata=12345&copydata=100000

This altered query string parameter will lead to copying 10000 data in place of 1 user data. 

Mitigation

From the above example, it’s clear that query string manipulation can cause damage beyond one’s understanding. Adopting best mitigation practices is a must to keep the risk under control. 

To make this happen, security personnel have to confirm that every time a parameter travels from client to server, a verified session tone tugs along. It doesn’t matter whether the session token used is a cookie or a parameter. Its presence matters. Its additions improve the security of URL query strings. 

Also, the web application should be guided to confirm the authenticity of the user before taking action against it. Parameters should only be processed or operated once it’s confirmed that they come from verified sources and are safe to further processing. 

To prevent double query string tampering, it’s important to understand that a parameter shouldn’t be used as a URL or a hidden field. If that’s not ensured then users are allowed to modify the parameters and this is where the problem starts.

Additionally, it’s very crucial that a user isn’t allowed to see the parameter value. It should be implemented with no exceptions. Even a user shouldn’t be allowed to see the password in the parameter. 

For sensitive parameters, the best preventive measure to be taken is adding a cryptographic key to them. Now, it could be done via two methods. The first way is to encrypt the whole query string and hidden form field values. This method works great for complete secrecy as users are not allowed to see or set the value. 

The other way to add cryptographic protection in the query strings is to introduce an extra parameter having a value of MD5 digest. It’s not as good as the first method as a user can modify the value. 

‍

Cookie

A cookie is a minute information section featuring details like search items, session tokens, browsing preferences, and so on. It’s produced by the server and is collected by the browser. As long as cookies are used for allotted purposes like understanding the browser’s preferences and search item details, they are harmless. The concerning aspect of cookies is that they are easy to modify by the client and get along with URL requests.

Taking the advantage of this vulnerability, a hacker can use cookies to steal crucial information. A skilled hacker can use all sorts of cookies, persistent or non-persistent cookies, secure or insecure, to carry out a cookie-based parameter tampering attack. 

Many of us think that non-persistent cookies are not modifiable. But, it’s a misconception as tools like Winhex makes non-persistent cookies easy to modify. Also, SSL protection works until a cookie is in transit. After that, all the cookies are unprotected. 

Mostly, the cookie manipulation involves arrays and session tokens, crucial for user authorization. Cookie manipulation is easy to carry out because most cookies are backed with an old-school and incompetent Base64 encoding scheme. This scheme lacks cryptographic protection. Hence, hackers don’t have to work very hard. 

Mitigation 

Even though cookie manipulation is easy for hackers, enforcing the right and strong mitigation techniques will reduce the dangers greatly. One of the most viable and easy mitigation techniques is to use one session token. 

This session token should be linked with reference properties, warehoused at the server-side cache. This is done to ensure that the data remains sane during the transit and returns as a stable resource as it’s based on the principle of not trusting user inputs featuring pre-determined or defined values. 

While you’re constructing the cookie-based preferences, make sure that the web application has to pay attention to the user property. To make this happen, the application must check the user ID along with its corresponding session table. 

Taking the help of intrusion detection hooks also works well when a cookie is under evaluation for the presence of unacceptable or impossible values that create the foundation of cookie tempering. 

Finally, encrypting cookies is crucial to stop tempering in the early stage. Now, the concerning question here is, how to encrypt cookies? 

Well, you can make this happen via methods like cookie hashing, symmetric encryption, and a detailed comparison of hashes upon arrival. 

HTML Form Field

An HTML form field is a company of HTML page, generated when a web application user makes a selection. This selection is stored as HTML form field values and is forwarded to the web application in the form of an HTTP request. 

Mostly, GET and POST requests feature it. Along with the HTML form field, an HTML request can store field value in the form of Hidden Fields as well. However, hidden fields aren’t displayed by the browser. They are only collected and submitted in the form of the parameter at the time of form submission.

Regardless of the type, all the HTML form fields are available for user-side manipulation. End-users can add whatever value they want and control the HTML request processing. The most common values picked are editing the HTML, view source, and save.

Let’s understand this with the help of an example.

Say, there is a web application using a basic form for username and password details submission. The application is using HTTP requests and is backed by SSL encryption. On the frontend, it has 2 fields named Username and Password for the user to log in, in case his identity is verified.

In case an application or developer doesn’t want to enter a long username or password, pre-defining the maximum length of these values will help. This also prevents the insertion of buffer overflow of long parameters.

But, a skilled hacker can find a way to deal with this. S/he will simply save the page, delete the maximum length tag, and access the page once again in the private browser. This way, HTML form field parameter tampering is possible.

Some very commonly used form field parameters used for tempering are value, read-only, and disabled.

For developers, hidden form fields act like an easy in-browser data storage and are widely used in the wizard-based application for data transport.  

Mitigation

The dangers of HTML form fields are various and must be avoided. This is why we’re going to explain key mitigation techniques. The first widely used technique is replacing the hidden form fields with one session token.

As hidden form fields are not visible, any tempering involving hidden form fields isn’t easy to spot. However, it could seem too daunting to many.

If that’s the case with you, the second mitigation approach to adopt is to combine the name/value pair, present in the hidden fields of a form, in a single string. Not many of us know this but there is a secret key that never comes into the public eye. It’s known as Outgoing Form Message. One can add it to the form field as extra hidden fields. 

Once the form, featuring the Outgoing Form Message, is presented, incoming name/value pairs are bridged together into an Incoming Form Message with a secret key. Afterward, an MD5 digest for the Incoming Form Message is automatically computed. 

When both the Incoming and Outgoing Form Digest are collected, they are compared thoroughly. If both values don’t coincide, it’s sure that the hidden field is modified or tampered. 

However, to maintain the accuracy of the whole process, the name/pair values of both the Outgoing and Incoming Form Messages must be linked in the same order and format.

Along with HTML Form Field tempering, this parameter tampering mitigation technique works in the case of URL tampering.

‍

How to prevent parameter tampering vulnerability?

If not handled properly for web or API, this issue can cause huge havoc. Hence, API security experts suggest adopting early and viable parameter tampering prevention techniques. We present you with the best options for you:

• Using a whitelist format for both client-side and server-side inputs - Whitelisting is a standard process of allowing requests or inputs only if they match the pre-defined and administer approved.
• A Firewall - It is a great way to control incoming and outgoing traffic to reduce security risks. Using a feature-rich cloud WAF provides extra security as it can handle APIs or microservices stored in any ecosystem.
• Encryption - Usin it for the user session cookies is an easy way to keep the possibility of tampering under control.
• No Explicit Passing - As mentioned above, any client-side cookie shouldn’t be a part of any key security choices. Parameters that aren’t a part of query strings are less prone to parameter tampering.

Ending Notes

The security of digital solutions must be the first concern of any developer. Fixing the web or API parameter tampering should be a part of any viable security practice and methods like using encryption, keeping client-side cookies out of key security decisions, and using an effective cloud WAF can help you in this regard.