通过 https 在 javascript 变量中将密码从服务器传递到浏览器安全吗？
以下是我们的页面流程，
- 用户位于通过 https 访问的登录页面。
- 用户输入密码并提交页面（POST 方法）。
- 用户凭据现在未经过身份验证，而是使用某些轮询页面（https）进行服务器响应。
- 为了保留轮询页面上的密码，密码通过 Javascript 变量和轮询页面的 onsubmit 从服务器传递到浏览器，密码通过 POST 方法传递。现在服务器验证用户凭据。
问题： 通过 https 在 javascript 变量中将密码从服务器传递到浏览器安全吗？
我的意见
- 之间的整个交易 浏览器和服务器通过 https 和 密码通过 POST 方法传递 - 所以密码是安全的。
- 密码可通过“查看 页面源”，因为它被分配给 javascript 变量 - 不安全如果 浏览器插件可以访问 页面内容。但如果浏览器插件 可以访问页面内容 甚至可以在用户输入密码时访问密码，因此无需新的 此流程引入了威胁。
注意
- 我知道他们是更好的处理方式 这个流量。但我感兴趣 我们现有的流程是否安全 或不。
- 任何对安全提示的引用都会 乐于助人。
Following is our page flow,
- User is at Login page accessing via https.
- User enters password and page is submitted (POST method).
- User credentials is not authenticated now instead server response with some polling page(https).
- In order to retain the password on poll page, password is passed from server to browser via Javascript variable and onsubmit of poll page, password is passed via POST method. Now server authenticates the user credentials.
Question:
Is passing password from server to browser in javascript variable over https secure?
My opinion
- Entire transaction between the
browser and server is via https and
password is passed via POST method -
so password is SECURE. - The password is visible via "view
page source" since it is assigned to
a javascript variable - NOT SECURE if
browser plug-in has access to the
page content. But if browser plug-in
has access to page content then it
can even access the password while user enters it, so NO new
threat is introduced by this flow.
Note
- I know their is better way to handle
this flow. But I am interested in
whether our existing flow is secure
or not. - Any reference to security tips will
be helpful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
更大的问题是最佳实践——你只是不需要这样做，而且这是不好的实践。这表明对整体安全性的理解很差 - 最佳实践是永远不要以明文形式存储密码。如果你的程序员同事没有充分相信这个概念，那么我建议他们可能在其他领域在安全方面观察不严。
安全是一种心态，而不是最低公分母。这是为了尽可能少地提供妥协的机会，并提供尽可能少的楔入空间。
不存储明文密码是你应该做的，而不是“在我们想要的时候存储它们，除非有人可以证明它是坏的”。
http://freedom-to-tinker.com/博客/felten/安全心态和无害的失败
The bigger issue is best practice - you just don't need to do it, and it's bad practice. This would indicate a poor understanding of security overall - it's a best practice to not store the password in plaintext ever. If your programmer coworkers do not give proper credence to this concept, then I would suggest they may have other areas they are lax in observing, security-wise.
Security is a mindset, not a lowest common denominator. It's about giving as few opportunities for compromise as possible, giving as little wedge room as possible.
Not storing plaintext passwords is what you should do, not "store them when we want unless someone can prove it's bad".
http://freedom-to-tinker.com/blog/felten/security-mindset-and-harmless-failures
传输将是安全的。但不建议将其与响应一起发送，因为浏览器会随页面缓存该值。有人可能会恶意查看页面源并查看密码。
您可以通过传递服务器会话密钥来做到这一点吗？
The transmission would be secure. But it would be inadvisable to send it with a response because browsers would cache the value with the page. Someone could maliciously view source of the page and view the password.
Could you do this by passing a server session key?
当然，交易本身可能不会受到某些形式的拦截，但是您将面临许多不依赖于拦截请求/响应活动的其他攻击。如果您网站的某些页面容易受到跨端脚本攻击并且某些恶意 JavaScript 出现在您的页面上怎么办？
Sure, the transactions themselves may be secure from some forms of interception, but you're opening yourself up to a number of other attacks that don't rely on intercepting the request/response activity. What if some page of your site is susceptible to cross side scripting and some malicious javascript gets on your page?