通过https安全将javascript密码从服务器传递到浏览器？

Question

以下是我们的网页流量，

1. 用户是通过HTTPS登录页面访问。
2. 用户输入密码并提交页面（POST方法）。
3. 用户凭证现在不通过身份验证，而是通过一些轮询页面（https）进行服务器响应。
4. 为了保留轮询页面上的密码，密码通过JavaScript变量和轮询页面的onsubmit从服务器传递到浏览器，密码通过POST方法传递。现在服务器验证用户凭证。

问题： 是通过https安全地将密码从服务器传递到浏览器的javascript变量？

我的意见

• 的 浏览器和服务器之间的整个事务是通过HTTPS和 密码是通过POST方法传递的 - 这样的密码是安全的。
• 的密码是通过“视图 页面源代码”可见，因为它被分配到 一个javascript变量 - 如果 浏览器插件可以访问 页面内容并不安全。但是，如果浏览器插件 可以访问页面内容，那么当用户输入密码时，它甚至可以访问密码，因此该流程不会引入新的 威胁。

注

• 我知道他们是更好的方式来处理这个 流。但我对 感兴趣，无论我们现有的流量是否安全 或不。
• 对安全提示的任何参考将对您有所帮助。

Answer 1

更大的问题是最佳实践 - 你只是不需要这样做，这是不好的做法。这表明对整体安全性的理解很差 - 最好不要以明文形式存储密码。如果你的程序员同事没有给出这个概念的适当信任，那么我会建议他们可能有其他方面的观察，安全明智的松懈。

Security is a mindset，不是最低公分母。这是为了尽可能减少妥协的机会，尽可能给予尽可能小的楔形空间。

不存储明文密码是你应该做的，而不是“当我们想要的时候存储它们，除非有人能证明它是坏的”。

对此感兴趣，“无害失败” - 情况下，恶意用户可以导致 异常但不直接有害 结果 - 是 安全观念的另一个标志。并非所有“无害 故障”导致大麻烦，但 这是令人惊讶的一个聪明的 攻击者可以多长时间堆积的 看似无害的故障堆栈成的麻烦一个 危险塔。无害 故障是不良的卫生。我们尽量将 戳掉。

http://freedom-to-tinker.com/blog/felten/security-mindset-and-harmless-failures

Answer 2

传输将是安全的。但发送响应并不合适，因为浏览器会将该值缓存在页面中。有人可能会恶意查看页面的来源并查看密码。

你可以通过传递服务器会话密钥来做到这一点吗？

Answer 3

当然，交易本身可能是安全的，不受某些拦截形式的影响，但是您可能面临许多其他不依赖拦截请求/响应活动的攻击。如果网站的某个页面容易受到跨页面脚本和恶意JavaScript的攻击，那该怎么办？