网络安全，隐藏字段（无敏感数据）是否存在问题？
我正在和同事讨论。 我们必须实施一些安全标准。 我们知道不要在隐藏字段中存储“敏感、地址、出生日期”信息，但一般来说，在您的应用程序中使用隐藏字段是否可以。
例如：
action=goback
似乎对此类信息使用隐藏字段比将其添加到查询字符串中更安全。 这是黑客可以用来攻击您的应用程序的又一信息。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
通过使用拦截代理（或任意数量的工具），黑客可以像访问查询字符串值一样轻松地访问隐藏字段。
我认为使用隐藏字段没有任何问题，只要它们不用于任何敏感内容并且您像验证来自客户端的任何其他值一样验证它们。
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.
使字段“隐藏”与安全性几乎无关，应该被视为 UI 决定。 无论如何，任何“黑客”都会读取您的 HTML 源代码。
最好根本不显示敏感信息，或者，如果必须的话，使用 SSL（以防止网络中介拦截数据）和登录挑战的某种组合（以防止未经授权的访问）。
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).
如果您公开最终用户无法获得的信息和/或在返回时未对其进行验证，则这只是一个安全漏洞。
我希望将所述信息存储在服务器端会话变量中......
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...
从安全角度来看，将数据存储在隐藏字段中与将数据存储在查询字符串中完全相同。 事实上，如果您的表单使用 GET 操作，那么无论如何它都会以查询字符串结束。
隐藏字段与安全性完全无关； 它们只是一种将数据存储在表单中的方法，而无需强迫用户查看它。 它们没有提供防止用户看到它的方法。
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.
隐藏字段并不总是一个问题，但它们应该始终敲响警钟，因为它们有两个潜在的问题：
1）如果数据敏感，它会将其暴露给客户端（例如使用代理，或者只是查看源代码 - 它是尝试以编程方式阻止这种情况是毫无意义的）
2）如果数据由服务器解释，则知识渊博的用户可以更改它。 举一个愚蠢的例子，如果隐藏字段包含用户的银行余额，他们可以使用代理或某些非标准客户端使服务器认为他们的银行余额是他们选择的任何内容。
第二个是网络应用程序中漏洞的一大来源。 与会话关联的数据应保存在服务器端，除非您有办法在服务器上验证它（例如，如果该字段由服务器签名或加密）。
只要您确定自己没有落入这些陷阱，就可以使用它们。 根据经验，我不会使用隐藏字段，除非您乐意在查询字符串中看到的数据，或者 javascript 需要它们进行处理。 在后一种情况下，您仍然需要确保服务器正在验证，但不要假设客户端将运行您的 JavaScript。
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.
出于篡改检查的目的考虑对隐藏字段的名称和值进行加密，因为黑客仍然可以获取您的隐藏字段并按照他们想要的方式操纵它们。
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.
正如其他人提到的，查询字符串和隐藏字段本质上都是公共数据，可供用户查看。
如果您将数据放在查询字符串上，需要记住的一件事是人们会传递 URL，因此永远不应该包含特定于当前用户的任何信息。
如果无法直接输入该状态，那么不要在 url 中包含状态信息也可能是个好主意。 或者至少您需要处理查询字符串中的无效状态信息。
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.
我想说这并不比将项目放入查询字符串更安全。 毕竟，人们总是可以在网站上查看源代码（并且没有任何方法可以阻止这种情况，因为人们总是可以以编程方式下载源代码）。
这里更好的解决方案是使用在服务器上生成的密钥（并且仅在服务器上）对字段的名称和值进行加密。 除非服务器被黑客攻击，否则客户端将不知道该值的名称是什么或其值。
当然，由于这是来自客户端的，您仍然需要检查返回的数据的有效性，不要想当然地认为它没有以您未指定的方式进行更改。
为此，您将需要使用散列来确保该值没有被篡改。
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.
一般来说，不要对敏感数据使用隐藏表单字段。 仅适用于您意识到“按收到的方式”处理不安全的静态非敏感 POST 数据。 我唯一使用它们的时候是在接收 POST 时渲染和检查会话令牌时存储会话令牌。 防止 CSRF 攻击或至少使攻击变得更加困难。
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.
除了其他发帖者提供的所有其他有用建议之外，我还想补充一点，隐藏字段使您的应用程序不像 url 查询字符串值那样容易受到 SQL 注入攻击。 一如既往，清理您的输入。
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.