Parameter Tampering

a simple attack targeting the application business logic

Parameter Tampering is a web-based business logic attack which involves manipulation of parameters exchanged between client and server in order to modify application data( user credentials and permissions, price and quantity of products, etc.).

Usually, this information is stored in Cookies, Hidden form fields, URL Query Strings, HTTP headers. The information(Application Data) is used to increase application functionality and control.

This attack can be performed by a malicious user who wants to exploit the application for their own benefit, or an attacker who wishes to attack a third- personusing a Man-in-the-middle attack. In both cases, tools like Webscarab and Paros proxy are mostly used.

Success of attack 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. Examples of Parameter Tampering :

No data sent to the browser can be relied upon to stay the same unless cryptographically protected at the application layer. Cryptographic protection in the transport layer (SSL) in no way protects one from attacks like parameter manipulation in which data is mangled before it hits the wire. Parameter tampering can often be done with:

● Cookies

● Form Fields

● URL Query Strings

● HTTP Headers

Cookies:

Cookies are the preferred method to maintain state in the stateless HTTP protocol. They are also used as a convenient mechanism to store user preferences and other data including session tokens.

Both persistent and non-persistent cookies, secure or insecure, can be modified by the client and sent to the server with URL requests. Therefore any malicious user can modify cookie content to his advantage.

Example:

Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ;

The attacker can simply modify the cookie to :

Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ;

HTTP Header :

HTTP headers are control information passed from web clients to web servers on HTTP requests, and from web servers to web clients on HTTP responses. Each header normally consists of a single line of ASCII text with a name and a value. Sample headers from a POST request follow.

Host: www.someplace.org

Pragma: no-cache

Cache-Control: no-cache

User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14

Referer: http://www.someplace.org/login.php

Content-type: application/x-www-form-urlencoded

Content-length: 49

An attacker will have to write his own program (about 15 lines of perl code will do) to perform the HTTP request, or he may use one of several freely available proxies that allow easy modification of any data sent from the browser.

Example 1:

Referer header which is sent by most browsers, normally contains the URL of the web page from which the request originated. Some websites choose to check this header in order to make sure the request originated from a page generated by them,

For example, in the belief it prevents attackers from saving web pages, modifying forms, and posting them off their own computer. This security mechanism will fail, as the attacker will be able to modify the Referer header to look like it came from the original site.

Example 2:

Accept-Language header indicates the preferred language(s) of the user.

A web application doing internationalization (i18n) may pick up the language label from the HTTP header and pass it to a database in order to look up a text.

If the content of the header is sent verbatim to the database, an attacker may be able to inject SQL commands by modifying the header.

Likewise, if the header content is used to build a name of a file from which to look up the correct language text, an attacker may be able to launch a path traversal attack.

Form Fields:

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 tampering 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.

URL Query Strings:

The URL query string is the query string, attached with the URL, after ?.

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

In this URL, the text after? is name=ferret and is the URL query string. URL query string comes with parameter value pair.

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.

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.

How to prevent parameter tampering vulnerability?

● 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 — Using it for the user session cookies is an easy way to keep the possibility of tampering under control.

● No Explicit Passing — 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.

References:

1. https://owasp.org/www-community/attacks/Web_Parameter_Tampering

2. https://infosecwriteups.com/what-is-parameter-tampering5b1beb12c5ba

3. https://www.cgisecurity.com/owasp/html/ch11s04.html

4. Article on Parameter Tampering in e-payments:

a. https://www.cobalt.io/blog/parameter-tampering-vulnerability-using-

3-different-approaches

5. https://www.wallarm.com/what/parameter-tampering-attack

6. Article on HTTP Parameter Pollution:

a. https://medium.com/geekculture/http-parameter-pollution-981af7894c6e