问题
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 fields but is it OK to use hidden fields for your application, in general.
For example:
action=goback
It seems like it would be safer to use hidden fields for that kind of information as opposed to adding it in the query string. It is one less piece of information that a hacker could use against your application.
回答1:
A hacker can access hidden fields just as easily as querystring values by using an intercepting proxy (or any number of tools).
I dont think there is anything wrong with using hidden fields as long as they aren't used for anything sensitive and you validate them like you would any other value from the client.
回答2:
Making a field "hidden" has pretty much nothing to do with security, and should be considered a UI decision. Any "hacker" will read your HTML source anyway.
Better to either not show sensitive information at all, or, if you must, to use SSL (to prevent data interception by network intermediaries) and some combination of login challenges (to prevent unauthorized access).
回答3:
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...
回答4:
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.
回答5:
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.
回答6:
As other people have mentioned both the query string and hidden fields are essentially public data, viewable by the user.
One thing to keep in mind if you place data on the querystring is that people pass urls around, and because of this should never contain any information specific to the current user.
It is also probably a good idea not to include state information in the url, if that state can not be entered directly. Or at least you would need to handle invalid state information in the querystring.
回答7:
Consider encrypting the name and value of your hidden field for the purpose of tamper checking since hackers can still get hold of your hidden fields and manipulate them the way they wanted to.
回答8:
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.
回答9:
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.
回答10:
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.
来源：https://stackoverflow.com/questions/413802/web-security-are-there-issues-with-hidden-fields-no-sensitive-data