Prevent hidden input from being altered

Question

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.

Solution 1

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.

Solution 2

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.

Solution 3

You can't. A rule to always remember that will save you a lot of thinking and design time. If the browser has it, its not secure.

Solution 4

If you are bent upon avoiding the server postback to validate input, you could base64 encode your hidden input and atleast make it harder for people out to tamper with it.

View more solutions

Comments

[Halcyon]

+1 If you have data that the user should not modify .. don't let him. Even keeping them in JavaScript might be a problem as they can still be tampered with.

[Halcyon]

But moot without 2 paragraphs explaining why ;)

[CyberJunkie]

Thank you! I am convinced that session storing is a sufficient solution for this. Should the user modify the value to banana it's his loss.

[CyberJunkie]

Thank you! I think session variables are a good solution. Voted best answer for additional ideas :)

[James]

if your secret key is on the client side, it's not so secret. The server can prevent the client from tampering with data it generated, but with current browser standards, it can never verify that data it receives was generated by the code it sent to the client.

[Darien]

@James I'm not sure what you mean, given that it's "a secret key known only to the server". Also, there is no "data generated by code sent to the client", this is all server-side computation. However, it's true that option #2 should also contain an HMAC step for added security, so I'm going to edit that in.