Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Prevent hidden input from being altered

This has been stressing me out.. I have a hidden input:

<input type="hidden" value="North Miami" name="city">

I'm populating the hidden input with valid city names via javascript prior to submitting the form. Suppose someone wants to submit Banana instead of a city name. The culprit can easily alter the input value via DOM inspectors like Firebug.

How can I ensure that the hidden inputs are not tampered with? I'm already validating the input against attacks but as long as I'm accepting alphabetical characters, anything can be submitted, hence banana...

Edit: I'm referring to hidden inputs in general, not just city names. Any value populated by a script and a value that must be submitted unaltered.

like image 684
CyberJunkie Avatar asked Jun 10 '11 22:06

CyberJunkie


People also ask

Are hidden inputs safe?

Since they are not rendered visible, hidden inputs are sometimes erroneously perceived as safe. But similar to session cookies, hidden form inputs store the software's state information client-side, instead of server-side. This makes it vulnerable.

Do hidden inputs get posted?

Even though the hidden input cannot be seen at all, its data is still submitted.

How do you make an input invisible?

The <input type="hidden"> defines a hidden input field. A hidden field lets web developers include data that cannot be seen or modified by users when a form is submitted.

Does a hidden input need a label?

An input with a type="submit" or type="button" does not need a label — the value attribute acts as the accessible label text instead. An input with type="hidden" is also fine without a label. But all other inputs, including <textarea> and <select> elements, are happiest with a label companion.


2 Answers

Some ideas:

  1. Server-side only. The easiest way to do this is to use session variables (like $_SESSION) so that all the data kept on the server side, but managing it and keeping separate tabs a user might have open separate can get a little tricky. This option prevents the user from seeing or editing the information.

  2. Make the client carry an encrypted blob. Take all your "temporary but protected" data, combine it somehow (e.g. JSON) and then encrypt* the whole thing with a secret key known only to the server. Base64 the result and put that into the hidden field value. (Note that for a high-security application, you'll also want to work an HMAC into this process, which validates that the ciphertext hasn't been tinkered with.) This option also prevents the user from seeing or editing the information, but makes it easier to handle cases where one user has many tabs open.

  3. Still use not-so-secret hidden input fields, but add an anti-tampering mechanism. So when the page is being generated, take all of your existing "protected" variables, combine them somehow with a server-side secret value, and hash [correction: HMAC] them. Store the hash in its own hidden field. Then after the user submits, you repeat the process and check if the hash matches. If it doesn't, have everything error with security-violation page.

*As with all cryptography, doing this the "right" way can be tricky and depends a lot on how you encrypt/verify. There are lot of pitfalls in terms of ciphers and cipher-modes etc.

Finally, remember that preventing people from modifying it doesn't mean a user can't copy everything and re-use it later or under another account, unless you take steps to include a "timestamp" etc.

like image 73
Darien Avatar answered Sep 29 '22 09:09

Darien


You can't. You can never, ever rely on user-submitted data. Even if you could prevent the user from modifying the DOM elements (which you can't), you could hardly stop them from submitting an HTTP request with cURL, wget or some other library with whatever fields they chose. Don't trust any data that is sent by the user.

If you want to ensure that the value doesn't change, you'll have to store it on the server. PHP has an excellent feature that allows you to do this -- sessions. Store the data in a session, and the user will not be able to modify it, because it will be stored on your server and never transferred to or from the user themselves.

like image 36
lonesomeday Avatar answered Sep 29 '22 10:09

lonesomeday