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