以下是我们的页面流程，
- 用户正在通过 https 访问登录页面。
- 用户输入密码并提交页面(POST 方法)。
- 现在不验证用户凭据，而是使用一些轮询页面 (https) 的服务器响应。
- 为了在投票页面上保留密码，密码通过 Javascript 变量从服务器传递到浏览器，在投票页面提交时，密码通过 POST 方法传递。现在服务器验证用户凭据。
问题: 通过 https 安全地将密码从服务器传递到浏览器中的 javascript 变量吗？
我的看法
- 之间的整个交易 浏览器和服务器是通过 https 和 密码通过 POST 方法传递 - 所以密码是安全的。
- 密码可通过“查看 页面源”，因为它被分配给 一个 javascript 变量 - 不安全，如果 浏览器插件可以访问 页面内容。但是如果浏览器插件 可以访问页面内容然后它 甚至可以在用户输入密码时访问密码，所以没有新的 此流程引入了威胁。
注意
- 我知道他们是更好的处理方式 这个流程。但我有兴趣 我们现有的流程是否安全 或不。
- 任何对安全提示的引用都将 乐于助人。
最佳答案
更大的问题是最佳实践 - 您只是不需要这样做，这是不好的做法。这表明对整体安全性的了解不足——最好不要以明文形式存储密码。如果您的程序员同事对这个概念没有给予适当的信任，那么我建议他们在安全方面可能还有其他方面松懈。
Security is a mindset ，不是最低公分母。这是关于尽可能少地提供妥协的机会，尽可能少地留出楔子空间。
不存储明文密码是你应该做的，而不是“在我们想要的时候存储它们，除非有人能证明它是坏的”。
This interest in "harmless failures" – cases where an adversary can cause an anomalous but not directly harmful outcome – is another hallmark of the security mindset. Not all "harmless failures" lead to big trouble, but it's surprising how often a clever adversary can pile up a stack of seemingly harmless failures into a dangerous tower of trouble. Harmless failures are bad hygiene. We try to stamp them out when we can.
http://freedom-to-tinker.com/blog/felten/security-mindset-and-harmless-failures
关于javascript - 通过 https 安全地将密码从服务器传递到 javascript 变量中的浏览器吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5364925/