是否通过https安全将密码从服务器传递到javascript变量中的浏览器？

Question

以下是我们的页面流程

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

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

我的意见

• 之间的整个交易 浏览器和服务器是通过https和 密码通过POST方法传递 - 所以密码是SECURE。
• 密码通过“查看”显示 页面源“因为它被分配给 一个javascript变量 - 如果不安全 浏览器插件可以访问 页面内容。但如果是浏览器插件 有权访问页面内容 甚至可以在用户输入时访问密码，所以没有新的 这种流程引入了威胁。

请注意

• 我知道他们是更好的办法 这个流程。但我感兴趣的是 我们现有的流量是否安全 或不。
• 任何对安全提示的引用都会 很乐意。

Answer 1

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

Security is a mindset，而不是最低的共同标准。这是为了尽可能少地提供妥协的机会，尽可能减少楔形空间。

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

  

对“无害的失败”的兴趣 -   攻击者可以造成攻击的情况   异常但不直接有害   结果 - 是另一个标志   安全心态。并非所有“无害   失败“导致大麻烦，但是   令人惊讶的是一个聪明的人   对手可以堆积一堆   看似无害的失败成了一个   危险的危险塔。无害   失败是不好的卫生。我们试着   我们可以把它们盖掉。

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

Answer 2

传输是安全的。但是，由于浏览器会使用页面缓存值，因此不建议使用响应发送它。有人可能会恶意查看该页面的来源并查看密码。

你能通过传递服务器会话密钥吗？

Answer 3

当然，事务本身可能对某些形式的拦截是安全的，但是您可以通过其他一些不依赖于拦截请求/响应活动的攻击来打开自己。如果您的网站的某些页面容易受到跨页脚本以及某些恶意javascript进入您的网页会怎样？