Parameter Tampering
According to OWASP, a web parameter tampering attack is “based on the manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc.” The compromised data is usually found in stored cookies, hidden form fields, or URL Query Strings and is intended for optimal site functionality.
In other words, there are unseen business logic gaps within the setup of a web server, web page, or web-based query where bad actors can get through. As OWASP continues, “the attack success depends on integrity and logic validation mechanism errors, and its exploitation can result in other consequences including XSS, SQL Injection, file inclusion, and path disclosure attacks.”
Common Examples
Common examples of Parameter Tampering techniques Api’s can fall prey to include the following:
Cross-Site Scripting
By taking advantage of a vulnerable input form, attackers can inject malicious code into a web page that will initiate every time an unsuspecting user clicks on the link. XSS attacks can then obtain cookies, session tokens or other valuable data intended for the legitimate website and even rewrite the HTML of the page.
SQL Injection
A SQL injection attack is designed to give the attacker access to back-end server information they otherwise would not have. Using an injection of malicious SQL code – a SQL query – hackers can trick the database into giving them unauthorized information. As OWASP states, “a successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.”
Hidden Fields
Often, sites will employ hidden fields to host status information for the Web application. Designed for ease of use, convenience also presents an issue. If a hidden field contains HTML specifying the price and quantity of an item, a hacker could find and alter the code, changing the price and scamming the organization out of the intended amount.
HTML GET
If an HTML form submits its results using the GET method, all form parameters will appear in the next URL query string the user sees and can subsequently be altered from there. For example, <http://www.examplebank.com/pretend.asp?accountnumber=123456> can be changed easily to <http://www.examplebank.com/pretend.asp?accountnumber=987654> and funds can be transferred to the wrong account.
URL Attribute Parameters
When it comes to viewing or sharing permissions, those can also be displayed and changed in the query string of the URL. As an example, a Web application that allows one user to view content only <http://www.examplebank.com/getpage.asp?id=111222&mode=readonly> could be tampered with to allow the same user to edit as well <http://www.examplebank.com/getpage.asp?id=111222&mode=readwrite>, changing what the user sees, what the customer sees, and what ultimately happens on the website.
Preventing Parameter Tampering Attacks
Fortunately, these schemes are easily preventable, making it easy to secure your API against these low-grade (but high payout) attacks.
Input validation
Proper security-mindedness in the programming stage (the “shift left” approach) is incredibly effective in combating XSS and SQL injection attacks. By denying certain characters, adding a strict character count, or allow listing, attackers will be limited in their scope and hopefully stymied in their attempts at data theft or command execution.
Never store critical data in hidden parameters
This might go without saying, but organizations should stop the practice of hiding critical data – product numbers, prices, numerical count – in either cookies or hidden parameters because this puts them and their data at inherent risk.
Web Application Firewall (WAF)
A Web Application Firewall (WAF) blocks bad IPs and filters and monitors HTTP traffic between the web application and the internet. It is signature-based and is designed to look for patterns and block known vulnerabilities. However, due to limited resources, WAFs are unable to decode nested encoding, inspect the entire payload, and handle all protocols - rendering them insufficient against modern API-targeted threats (and malicious traffic accounts for over 2.1% of all API traffic).
Rigorous application testing should be applied in addition to all of the above best practices, as spotting a vulnerability in development is far better than falling prey to one down the road.
Securing against modern threats
Ultimately, transaction-based attacks (the kind that rely on signatures) were a key attack vector of the past. Traditional methods – like a WAF – are designed to spot known patterns and act as a firewall, blocking the known threats and mitigating these challenges. However, as API usage has evolved, the attacks have too, and security must follow suit.
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.orgPragma: no-cacheCache-Control: no-cacheUser-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14Referer: http://www.xplace.org/login.phpContent-type: application/x-www-form-urlencodedContent-length: 86Most 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.
Tampering HTTP requests
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©data=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©data=100000
This altered query string parameter will lead to copying 10000 data in place of 1 user data.
URL Query Strings
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.