How To Work With Hidden field tampering : Web App hacks

Most of us who have dabbled with some HTML coding have come across the hidden field. For example, consider the code below: < input type="hidden" name="ref" size="20" value="http://www.website.com"> < input type="hidden" name="forref" size="20" value= ""> < input type="text" name="username" size="20" value="">

Most web applications rely on HTML forms to receive input from the user. However, users can choose to save the form to a file, edit it and then use the edited form to submit data back to the server. Herein lies the vulnerability, as this is a "stateless" interaction with the web application. HTTP transactions are connectionless, one-time transmissions.

The conventional way of checking for the continuity of connection is to check the state of the user from information stored at the user's end (Another pointer to the fallacy in trusting the client side data). This can be stored in a browser in three ways; cookies, encoded URLs and HTML form "hidden" fields

We will discuss cookies and encoded URLs elsewhere in this module.

"Hidden" fields are preferred by developers as it has lesser overhead and can hold a lot of information. However, these can be easily tampered with. For instance if an attacker saves a critical form such as authentication form onto his system, he can view the contents of the file/form including values in the "hidden" fields. Using a text editor, he can change any of the hidden fields as the web application can implicitly trust the user input taken by the hidden field.

One way of hedging this risk is to use the HTTP_REFERER header to capture the last page the user has visited. However, anybody with a little programming knowledge can write a script to render this check useless. CheckingHTTP_REFERER will catch trivial attempts to tamper with forms, but cannot be relied on for serious web applications. The bottom line is that anything sent back by a web browser: form fields, HTTP headers, and even cookies can all be tampered with and must be considered untrustworthy information.

Detecting "hidden" field tampering adds security in web applications, but for critical apps like e-commerce applications, hidden fields should be avoided at the design level. For instance, consider someone placing an order at amazon.com and briefly leaving their desk half-way through placing an order. Anyone with access to the computer can use "view source" to see the credit card information and other data stored in "hidden" fields (if it is being used). A best practice in developing web applications is to avoid storing vital information in "hidden" fields.

This is an online shopping cart using hidden field to pass the pricing information between the order processing system and the order fulfillment system. If the application does not use a backend mechanism to verify the flow of pricing information then altering the price will lead to the ability to buy product for smaller amounts and potentially even negative sums.