网络安全,隐藏字段是否存在问题(没有敏感数据)?

时间:2009-01-05 17:08:05

标签: html security hidden-fields

我和同事讨论过。我们必须实施一些安全标准。我们知道不会在隐藏字段中存储“敏感信息,地址,出生日期”信息,但通常可以在应用程序中使用隐藏字段。

例如:

action=goback

与在查询字符串中添加隐藏字段相比,使用隐藏字段更安全。这是黑客可以用来对你的应用程序提供的一小部分信息。

10 个答案:

答案 0 :(得分:20)

黑客可以通过使用拦截代理(或任意数量的工具)访问隐藏字段,就像查询字符串值一样容易。

我不认为使用隐藏字段有任何问题,只要它们不用于任何敏感信息,并且您可以像验证客户端的任何其他值一样验证它们。

答案 1 :(得分:6)

使字段“隐藏”几乎与安全性无关,应该被视为UI决策。无论如何,任何“黑客”都会阅读您的HTML源代码。

最好不要显示敏感信息,或者,如果必须,最好使用SSL(以防止网络中介拦截数据)和一些登录挑战组合(以防止未经授权的访问)。

答案 2 :(得分:5)

如果您公开了最终用户无法获得的信息和/或在返回时未对其进行验证,那么这只是一个安全漏洞。

我希望将所述信息存储在服务器端会话变量中而不是......

答案 3 :(得分:4)

从安全角度来看,将数据存储在隐藏字段中与将其存储在查询字符串中完全相同。实际上,如果您的表单使用GET操作,它最终会以查询字符串结束。

隐藏字段与安全完全无关;它们只是一种方法,通过该方法可以将数据存储在一个表单中,而无需强制用户查看它。它们没有提供阻止用户看到它的方式。

答案 4 :(得分:3)

隐藏字段并不总是一个问题,但它们应该总是响起警钟,因为它们有两个潜在的问题:

1)如果数据是敏感的,它会将其暴露给客户端(例如使用代理,或者只是查看源代码 - 尝试以编程方式阻止此操作是没有意义的)

2)如果服务器解释数据,知识渊博的用户可以更改它。举一个愚蠢的例子,如果隐藏字段包含用户的银行余额,他们可以使用代理或某些非标准客户端使服务器认为他们的银行余额是他们选择的任何东西。

第二个是webapps漏洞的重要来源。与会话相关联的数据应保留在服务器端,除非您有在服务器上验证它的方法(例如,如果该字段由服务器签名或加密)。

如果您确定没有陷入其中任何一个陷阱,可以使用它们。根据经验,我不会使用隐藏字段,除了您将很乐意在查询字符串中看到的数据,或者javascript是否需要它们进行处理。在后一种情况下,您仍然需要确保服务器正在验证,但不要假设客户端将运行您的javascript。

答案 5 :(得分:1)

正如其他人所提到的,查询字符串和隐藏字段本质上都是公共数据,可由用户查看。

如果您在查询字符串上放置数据,请记住的一件事是人们传递网址,因此不应包含特定于当前用户的任何信息。

如果无法直接输入状态,也不应在网址中包含状态信息。或者至少你需要在查询字符串中处理无效的状态信息。

答案 6 :(得分:1)

考虑加密隐藏字段的名称和值以进行篡改检查,因为黑客仍然可以抓住隐藏的字段并按照他们想要的方式操作它们。

答案 7 :(得分:0)

我想说这比将项放在查询字符串中更安全或更不安全。毕竟,人们总是可以在网站上查看源代码(并且没有任何方法可以防止这种情况,因为总是可以通过编程方式下载源代码。)

这里更好的解决方案是使用在服务器上生成的密钥加密字段名称和值,并且只加密服务器。除非服务器被黑客攻击,否则客户端不会知道值的名称或值。

当然,由于这是来自客户端,您仍然需要检查返回数据的有效性,不要理所当然地认为它没有以您没有指示的方式进行更改

为此,您需要使用散列来确保该值未被篡改。

答案 8 :(得分:0)

通常,请勿对隐藏的表单字段使用敏感数据。只有您认识到的静态非敏感POST数据才能安全地处理“收到的”。我使用它们的唯一时间是存储会话令牌,因为它们在接收POST时被呈现和检查。为了防止CSRF攻击或至少使它们变得更加困难。

答案 9 :(得分:0)

除了其他海报的所有其他有用的建议之外,我还要补充一点,隐藏字段使您的应用程序不会像url查询字符串值那样容易受到SQL注入攻击。一如既往,清理您的意见。