我正在和同事讨论。我们必须实施一些安全标准。我们知道不要将“敏感、地址、出生日期”信息存储在隐藏字段中，但通常可以为您的应用程序使用隐藏字段。
例如：
action=goback
与将其添加到查询字符串中相比，对此类信息使用隐藏字段似乎更安全。它是黑客可以用来攻击您的应用程序的少了一条信息。
Berlin Brown
问问题
24539 次
10 回答
22
黑客可以通过使用拦截代理（或任意数量的工具）访问隐藏字段，就像查询字符串值一样容易。
我不认为使用隐藏字段有什么问题，只要它们不用于任何敏感的内容，并且您可以像验证来自客户端的任何其他值一样验证它们。
于 2009-01-05T17:15:42.440 回答
6
使字段“隐藏”与安全性几乎无关，应该被视为 UI 决定。无论如何，任何“黑客”都会阅读您的 HTML 源代码。
最好是根本不显示敏感信息，或者，如果必须，使用 SSL（以防止网络中介拦截数据）和登录挑战的某种组合（以防止未经授权的访问）。
于 2009-01-05T17:10:58.223 回答
5
如果您要公开最终用户无法获得的信息和/或在返回时未对其进行验证，那么这只是一个安全漏洞。
我会改为将所述信息存储在服务器端会话变量中......
于 2009-01-05T17:15:53.143 回答
4
从安全的角度来看，将数据存储在隐藏字段中与将数据存储在查询字符串中完全相同。事实上，如果您的表单使用 GET 操作，无论如何它都会以查询字符串结束。
隐藏字段与安全性完全无关；它们只是一种可以将数据存储在表单中而无需强迫用户查看的方法。它们没有提供阻止用户看到它的方法。
于 2009-01-05T17:17:40.720 回答
3
隐藏字段并不总是一个问题，但它们应该始终敲响警钟，因为它们有两个潜在问题：
1）如果数据是敏感的，它将它暴露给客户端（例如使用代理，或者只是查看源 - 尝试以编程方式阻止这种情况是没有意义的）
2) 如果数据被服务器解释，有知识的用户可以改变它。举一个愚蠢的例子，如果隐藏字段包含用户的银行余额，他们可以使用代理或一些非标准客户端让服务器认为他们的银行余额是他们选择的任何东西。
第二个是 webapps 漏洞的一大来源。与会话关联的数据应保存在服务器端，除非您有一种在服务器上对其进行验证的方法（例如，如果该字段由服务器签名或加密）。
只要您确定自己没有落入这些陷阱中的任何一个，就可以使用它们。根据经验，我不会使用隐藏字段，除非您很乐意在查询字符串中看到数据，或者如果 javascript 需要它们进行处理。在后一种情况下，您仍然需要确保服务器正在验证，不要假设客户端会运行您的 javascript。
于 2009-01-05T17:34:11.717 回答
1
正如其他人所提到的，查询字符串和隐藏字段本质上都是公共数据，用户可以查看。
如果您将数据放在查询字符串上，要记住的一件事是人们会传递 url，因此不应包含任何特定于当前用户的信息。
如果不能直接输入该状态，那么在 url 中不包含状态信息可能也是一个好主意。或者至少您需要处理查询字符串中的无效状态信息。
于 2009-01-05T17:27:20.920 回答
1
考虑加密隐藏字段的名称和值以进行篡改检查，因为黑客仍然可以控制您的隐藏字段并以他们想要的方式操纵它们。
于 2010-04-08T18:36:53.877 回答
0
我会说这并不比将项目放在查询字符串中更安全。毕竟，人们总是可以在网站上查看源代码（并且没有任何方法可以防止这种情况发生，因为人们总是可以以编程方式下载源代码）。
这里更好的解决方案是使用在服务器上生成的密钥加密字段的名称和值，并且只加密服务器。除非服务器被黑客入侵，否则客户端不会知道值的名称是什么，或者它的值是什么。
当然，由于这是来自客户端，您仍然需要检查返回的数据的有效性，不要只是想当然地认为它没有以您没有指定的方式进行更改。
为此，您将需要使用散列来确保该值未被篡改。
于 2009-01-05T17:15:06.280 回答
0
一般来说，不要对敏感数据使用隐藏的表单字段。仅适用于您意识到处理“收到的”不安全的静态非敏感 POST 数据。我唯一一次使用它们是存储会话令牌，因为它们在收到 POST 时被渲染和检查。为了防止 CSRF 攻击或至少使它们变得更加困难。
于 2009-01-05T17:17:37.443 回答
0
除了其他发帖人提供的所有其他有用建议之外，我还要补充一点，隐藏字段使您的应用程序不会像 url 查询字符串值那样容易受到 SQL 注入攻击。与往常一样，清理您的输入。
于 2009-01-05T17:48:21.003 回答