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.
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.
Even though the hidden input cannot be seen at all, its data is still submitted.
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.
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.
Some ideas:
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.
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With