Tim TrottTim TrottAlways hope, never expect

Parameter Tampering and How to Protect Against It

By , Sunday 10th July 2016 in Security & Privacy

parameter tampering is a method by which malicious hackers attempt to compromise your application through manipulating parameters in the URL string. This can cause applications to perform in ways the programmer did not intend, especially if invalid data is encountered.

Parameter tampering focuses on a vulnerability in the way an application handles untrusted data. This can be from things like failure to check data integrity, malicious intent, SQL injection, cross site scripting or even binaries containing malware.

Parameter tampering is merely changing the value of a GET or POST variable in the URL address bar by means other than normal application usage. The untrusted data can also can also come from the request headers or from cookies, so there are a number of attack vectors which must be addressed.

Request Headers

We've seen request headers before so this shouldn't be unfamiliar. Looking at the data we can see that there are at least a dozen areas in which data can be manipulated, so lets have a look at a sample header and the possible areas that may become compromised.

public class UserProfile
{
  public string Email { get; set; }
  public string FirstName { get; set; }
  public bool IsAdmin { get; set; }
  public string LastName { get; set; }
  public string Password { get; set; }
  public int UserId { get; set; }
}

A model will commonly link through to a table in a database, maybe even a 1:1 relation with the table and the model.

Model binding is the process by which the application will automatically try and populate a model with data from the payload.

Consider a account settings page in which a user can edit their information. Models are generally linked in with a form, each field in the form is bound to a property on the class. In this example the user can edit their email address, first name and last name. A common construct is to have hidden fields for entity id's, in this case the UserId. This is a hidden text box in the form which is not shown to the user, but is automatically populated with the current users ID and sent back to the server when the form is submitted.

Hopefully you can start to see some problems with this. Firstly, what happens if the the UserID is tampered with? Can we change the name and email address of another user? Is the email address validated?

The main risk however is due to the fact that model binding is an automatic process in most frameworks. That means that any POST parameter matching a model property is auto mapped to the entity. If this entity is then written back to the database during an update without proper validation there could be serious consequences. We'll see an example of this in just a second.

Mass Assignment Attacks

A mass assignment attack is a type of parameter tampering where a bunch of fields on the model are assigned to from the POST parameters. In the example above, a legitimate payload may look like

POST /index.php
?FirstName=john&LastName=smith&email=john.smith@example.com

Now this can be manipulated quite easily to form a mass assignment attack. It will take one of two forms. Either an attacker has created a fingerprint of your server and software through internal implementation disclosure and knows what platform you are running on and can tailor the attack, or it will be a brute force style attack.

If you are running on an open source platform, such as WordPress, Joomla, Drupal, Umbraco et al, then all the attacker has to do is look at the source code for the models. A brute force attack literally bombards the server with requests.

A malicious hacker would then send a payload with a crafted variable to assign a value to the model to bypass the security. In this example, making the user an admin.

POST /index.php
?FirstName=john&LastName=smith&email=john.smith@example.com&IsAdmin=true

Through the wonders of automagic, this value is then parsed into the model, which is then persisted through to the database and voila, the user is now an admin.

This can be rectified by not using a view model which is the same as the database entity. The view model should only contain the fields which are actually in use, and the values should be inspected prior to any database updates.

Fuzz Testing

Fuzz testing is an automated tool which brute force attacks specific payloads with a dictionary of patterns to find vulnerabilities. It does exactly the same as manual parameter tampering, however it is an automated process testing multiple combinations of each parameter with multiple patterns and it analyses the results. The tool can scan for cross site scripting, SQL injection and directory traversal (patterns which can potentially access system files).

There are many tools available for this, including the OWASP Zed Attack Proxy. Just here though we are going to use the very simple addon to Fiddler called Intruder21.

What we are going to do here is perform a search, capture the request in Fiddler then run Intruder21 over the request to see if it can detect anything. Fire up Fiddler, make sure it is capturing traffic then make a request to a site and perform a search. In Fiddler, locate the request to the search, right click and select Send to Intruder21.

In this window you can see all the parameters in the request. It sometime highlights properties which it thinks could be manipulated, but it doesn't always capture them all. I'm only interested in the search for now, so clear the results, locate the search term in the url or request body, highlight it and click Add Tag.

Fuzz Testing with Intruder21
Fuzz Testing with Intruder21

Now, in the payloads tab you can see all the different values the program will try and substitute in for the search term. Basically it will go though each payload and search for that term. It will then analyse the results to see if they match expected behaviour.

Click on the results tab, then start test to begin. After a while it will come back with the results.

Fuzz Testing with Intruder21
Fuzz Testing with Intruder21

It looks like my website was ok, but if there were any orange or red lines that means that Intruder21 has identified possible attack vectors which can be used and should be addressed immediately.

Key Points to take away

You must assume that all aspects of HTTP request can and will be manipulated by attackers. The verb, path, protocol, accept headers, user agent strings, referrers, accept language, cookies and the request body are all untrusted data.

Don't rely on controls which depend on the browser - don't depend on client side validation.

Be conscious of where risks might be present in automated processes such as model binding and mass assignment attacks.

Consider which verbs should be allowed for a resource and block the others.

Fuzz test any and all properties where an attacker may attempt to gain access.

My website and its content are free to use without the clutter of adverts, tracking cookies, marketing messages or anything else like that. If you enjoyed reading this article, or it helped you in some way, all I ask in return is you leave a comment below or share this page with your friends. Thank you.

About the Author

Tim Trott

Tim is a professional software engineer, designer, photographer and astronomer from the United Kingdom. You can follow him on Twitter to get the latest updates.

Leave a Reply

Your email address will not be published.