假设您有一个在隐藏表单字段中传递用户名和密码的Web应用程序。
我知道这是一个非常糟糕的主意,但我有兴趣列举为什么......有什么想法?
更新 - 这是一个假设的问题。
我找不到一个只列举原因的资源 - 我知道为什么这是一个坏主意的很多原因,我想看看是否还有其他原因我没有想到并创建该资源我在寻找。谢谢!
答案 0 :(得分:9)
为什么这是一个糟糕的想法的原因有很多:
1)正如所指出的,如果您查看source,inspect元素或类似内容,则很容易发现用户名/密码。
2)除非您的传输层已加密,否则很容易被截获。
3)如果浏览器缓存了你的html页面,那么带有用户名/密码的文件现在存储在该人的计算机上。
4)如果该用户保存页面以便提供给其他人,那么他们的用户名/密码将与该页面一致。
5)POST方法意外地变为GET,现在密码和用户名存储在服务器访问日志中....
Etc等。
在我看来,没有任何理由这样做,特别是当您可以在服务器上使用会话cookie时,或其他一些不向客户端公开私人信息的方法。
编辑:想想看,我以前做过一次。我把一个密码放在一个隐藏的字段中,但是在这之前我用一个只有服务器知道的密钥加密才能打印出来,然后当我把密码发回给服务器时,我解密了它。因此,明文密码永远不会与客户端密切相关。
编辑2 :应该指出,根据hobbs指出,上一次编辑中描述的方法并未用于直接验证某人。
答案 1 :(得分:3)
任何有权访问当前页面的人(可能不一定是登录您的应用程序的人)都很容易查看html源并获取用户名和密码。
如果我登录我的Gmail,然后离开我的办公桌,你就进来了,你可以看到我的所有电子邮件。但无论你不能看到我的Gmail密码。但是如果gmail以隐藏字段格式传递密码,那么可以查看我的Gmail密码。
答案 2 :(得分:3)
在所有情况下,包含用户名和密码的内容可能会提供给不应该看到它的人。
答案 3 :(得分:2)
我不认为在纯文本中存储用户名是如此糟糕,在某些情况下这样做可能会有所帮助。
然而,存储密码是另一回事。有人可以很容易地通过网络对您的数据进行数据包嗅探(其中可能会发生许多事情)并使用您的凭据登录。
我遵循的黄金法则永远不会在任何地方存储明文密码。
答案 4 :(得分:2)
我认为这里最大的风险是任何XSS漏洞现在都允许密码窃取。 XSS比看起来要糟糕得多。 XSS漏洞并没有任何借口,但是人们做出的决定使得它们变得相当不可避免。
也许第二大风险是缓存。这些密码将最终存储在磁盘上,并可用于通过文件拖网的任何恶意代码。话虽如此,大多数密码都可以通过交换和休眠结束在磁盘上 - 这就成了概率问题。
答案 5 :(得分:2)
通常,当我需要一个官方资源来列出可能的攻击或弱点时,我转向:
常见的弱点列举 http://cwe.mitre.org/
常见攻击模式枚举和分类 http://capec.mitre.org/
软件安全错误的分类 http://www.fortify.com/vulncat/
令人惊讶的是,将用户名/密码存储在隐藏的表单字段中是一个如此严重的错误,它会在CWE中遇到大约20个问题。
只是为了让你开始:
http://cwe.mitre.org/data/definitions/352.html
http://cwe.mitre.org/data/slices/384.html
http://cwe.mitre.org/data/definitions/471.html
http://cwe.mitre.org/data/definitions/472.html
http://cwe.mitre.org/data/definitions/639.html
答案 6 :(得分:1)
嗯,危险因“用户名和密码”的含义而异。
如果您指的是要验证的用户名和密码,我邀请您在网络浏览器中选择View-> Source。这完全没有安全性。
如果您指的是在发送之前登录的用户的用户名和密码被放置在隐藏字段中,那么它与您的标准文本和密码字段之间绝对没有区别。这里唯一的安全风险是密码在没有TLS / SSL连接的情况下被清除,以加密它,允许数据包嗅探以查看凭证。
答案 7 :(得分:0)
窃听,尤其是传输层未加密时
答案 8 :(得分:0)
除非你的所有网页都是通过https提供的,否则这很糟糕,因为用户名和密码是通过网络以明文形式发送的,并且可以嗅探。 即使所有页面都通过https提供,也很糟糕,因为如果用户忘记关闭他/她的浏览器,任何有权访问该计算机的人都可以查看源并读取密码。 它给用户一种虚假的安全感,我建议你尽可能地改变它。