An Introduction to Form Field Manipulation

You use web forms all the time. All across the internet, you are called upon to give certain information about yourself in order to access a site, use an application, or purchase a product. And the truth is most of us have become more open to these kinds of interactions as we have become immersed in the World Wide Web. Of course, you wouldn’t even think of trying to manipulate that data to your own advantage. But the bad guys would.

Altering Field Data

Form field manipulation occurs when a hacker tries to alter the behavior of a form by illegitimately changing the data sent to the web server. Along with cookie manipulation, this exploit falls within a larger classification called web parameter tampering. In another article, we discussed how a hacker may attempt to hijack a cookie for the purposes of changing some parameter data. There are bad guys who try to do the same thing with form parameters.

Form field manipulation occurs when a hacker tries to alter the behavior of a form by illegitimately changing the data sent to the web server.

So how might a hacker know the contents of your web form? It’s easy. Right-click on any web page and click on the menu item “view source code”. You will see a lot of html code that is the actual text that runs that web page. If you’re not careful, an attacker could just make a few changes to your source code and do a lot of harm.

The Attacker’s Tactics

One way that someone could alter a form field is simply to right-click a form, cut and paste the source code into another file, make a few changes, then run it again through the browser. Suppose the form was used for making a purchase. Here’s an example borrowed from OWASP that includes a “hidden” field:

<input type=”hidden” id=”1008” name=”cost” value=”70.00”>

A hacker who wants to get a 90% discount could just change the value from 70.00 to 7.00. The tactic is so simple. But by now developers should know enough to prevent such mischief.

Along with changing values that humans can easily read, a clever hacker can also inject code. This is similar to the SQL injection exploit. But in this case the malicious code is placed into the altered form. Here’s an example from the website Security Focus, first the original code:

<form>

<input type="hidden" name="username" value="Joe User" >

</form>

Now suppose instead of “Joe User”, the hacker alters the field by adding an HTML tag to close a parameter, and then points to a script:

"> <script>alert(document.cookie)</script> <a name ="

As you can see, the form is no longer just accepting a username value. It’s running a malicious script.

The Ugly Truth

We can’t know what goes through a hacker’s mind, but sometimes his purposes are clear. An attacker can change prices in web checkout carts or modify the behavior and appearance of web pages. He can seek to impersonate users or access privileged or confidential data.

Sometimes a hacker just wants to prove that he can do it. The attack becomes an intellectual challenge, and its success may be a badge of honor that he shares anonymously across the dark web, or with his hacker buddies in a college dorm room.

The ugly truth is that there are plenty of technically-minded individuals with bad intentions — or at least without the integrity and self-control that keeps most people from such dubious acts. There is nothing that we can do to change this fact. We can only defend against it.

Protect Your Forms

The best advice is not to put important data, such as the price of product, in plain view. Just because it is in a “hidden” field doesn’t mean you can’t find it. It’s only hidden when running the page. The field and its data are easily found in the page source. Rather than using a hidden field, such data can easily be stored in a backend database.

“The best way to prevent parameter tampering is to ensure that all parameters are validated before they are used.”

Another way to mitigate against form field tampering is to sanitize the data. That means you use code that “escapes out” of any unwanted special characters. An OWASP article on Unvalidated Input states the issue clearly:  “The best way to prevent parameter tampering is to ensure that all parameters are validated before they are used.” This involves using a centralized library to standardize the format of parameters used in forms. Today this protection is sometimes included in web application firewalls.

Another site offering mitigation techniques for form field manipulations suggests the use of a session token to authenticate any transactions. It also says that something called a “secret key” can be used to encrypt and decrypt messages. That is in contrast to public key cryptography. However it is implemented, encryption is a good idea. The advice to use encryption given in a 2001 paper on “Preventing HTML form tampering” still rings true today.

Conclusion

Any time that data is transmitted from a user to a web server, there is a chance that it can be intercepted, captured, altered, or otherwise tampered with. Users should be aware of the vulnerability. And developers and website owners should be sure that they have provided protections against it. We can introduce you to the threat, but we can’t provide all the answers here. If you really want to establish the proper defenses to protect against web attacks like form field manipulation, you might have a bit more homework to do on your own. For a quick fix, consider Total Uptime’s Web Application and API Protection (WAAP) service which can enable you to implement protections against Form Field Manipulation within minutes.