Web security, are there issues with hidden fields (no sensitive data)?

Question

I was having a discussion with coworkers. We have to implement some security standards. We know not to store \'sensitive, addresses, date of birth\' information in hidden

Answer 1

It's only a security hole if you're exposing information that wouldn't be otherwise available to the end user and/or aren't validating it on return.

I'd look instead to storing said information in a server side session variable instead...

Answer 2

Storing your data in a hidden field is, from a security standpoint, exactly the same as storing it in the query string. In fact, if your form uses the GET action, it ends up int he query string anyway.

Hidden fields are completely unrelated to security in any way; they are simply a method by which data can be stored in a form without forcing the user to see it. They do not provide a way of preventing the user from seeing it.

Answer 3

In addition to all the other useful advice by other posters, I'd also add that hidden fields make your app no less vulnerable to SQL injection attacks as url query string values do. As always, sanitise your input.

Answer 4

Hidden fields are not always an issue, but they should always ring alarm bells as they have two potential problems:

1) If the data is sensitive, it exposes it to the client (e.g. using a proxy, or simply view source - and it is pointless to try and prevent this programmatically)

2) If the data is interpreted by the server, a knowledgeable user can change it. To take a silly example, if the hidden field contains the user's bank balance, they could use a proxy or some non standard client to make the server think their bank balance is anything they choose.

The second one is a big source of vulnerabilities in webapps. Data associated with the session should be held server side, unless you have a means of validating it on the server (for example if the field is signed or encrypted by the server).

Provided you are sure you're not falling into either of these traps, they can be OK to use. As a rule of thumb, I would not use hidden fields except for data you would be happy to see in the query string, or if javascript needs them for processing. In the latter case, you still need to make sure the server is validating though, don't assume the client will run your javascript.

Answer 5

I would say that this is no more or less safe than placing the item in the query string. After all, one could always view source on the site (and there isn't any way to prevent that, since one could always programmatically download the source).

A better solution here would be to encrypt the names of the fields and the values with a key that is generated on the server, and only the server. Unless the server was hacked, the client wouldn't have any clue what the name of the value is, or its value.

Of course, since this is coming from the client, you still have to check the validity of the data coming back, don't just take for granted that it hasn't been altered in a manner that you didn't dictate.

To that end, you will want to use hashing to make sure that the value hasn't been tampered.

Answer 6

In general don't use hidden form fields for sensitive data. Only for static non sensitive POST data that you realise is not safe to handle "as its recieved". The only time i use them is to store Session Tokens as they're rendered and checked upon recieving the POST. To prevent CSRF attacks or atleast make them a great deal harder.