SSL iframe 中的用户身份验证
我的 Web 应用程序受到越来越多的关注，我需要提供额外的安全性来保护我的客户。
我认为最大的问题是用户登录数据以纯文本形式发送。我提出这个问题的目标是辨别以下方法是否是一种改进。
此外，我将需要为我的服务获取专用服务器。在此之前，所提出的解决方案是暂时的。
我目前正在共享托管 Web 服务器上运行我的 Web 应用程序，该服务器仅通过自己的域提供 SSL。
http://mydomain.com
相当于
https://mydomain-com.secureserver.com
我的想法是：
http://mydomain.com/login.php
...其中 iframe 从安全服务器打开一个页面，如下所示：
<iframe src="http://mydomain-com.secureserver.com/ssllogin.php"></iframe>
- 我对用户进行身份验证 ssllogin.php 带有 (hashed+(per 基于用户的随机加盐）） 来自数据库的密码。
- 正确的会话重新生成后，设置验证身份验证的会话。
- 然后以某种方式在 http://mydomain.com 上传输和验证此会话
这种方法是否可以实现？这是否会提高我的登录安全性，或者只是将攻击者的“密码拦截点”移至另一个实例？
感谢所有反馈。
My web application is receiving increased attention and I need to provide additional security to protect my customers.
The biggest problem as I see it is that the user login data is sent as plain text. My goal with this question is to discern if the following approach is an improvement or not.
In extension I will need to get dedicated servers for my service. This proposed solution is temporary until then.
I am currently running my web application on a shared hosting web server which only provides SSL through their own domain.
http://mydomain.com
is equivalent to
https://mydomain-com.secureserver.com
My thought is to have:
http://mydomain.com/login.php
...in which an iframe opens a page from the secure server, something like this:
<iframe src="http://mydomain-com.secureserver.com/ssllogin.php"></iframe>
- I authenticate the user in
ssllogin.php with the (hashed+(per
user based-randomly salted))
passwords from the database. - After proper session regeneration set a session verifying the authentication.
- This session is then somehow transferred and verified on http://mydomain.com
Is this approach even possible to achieve? Would this be an improvement of my login security or just move the "point of interception of password" for the attacker to another instance?
All feedback is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你不需要 iframe。只需将登录表单的操作指向 https://yourdomain.com/login.php 即可。在那里您可以检查用户是否＆amp;密码正确，然后再次重定向到纯 http。
但是这并不是100%安全的。事实上，您正在向用户发送&通过 https 的密码可能会阻止攻击者或嗅探器获取该密码。但是，如果您稍后恢复为纯 http，则此攻击者/嗅探器可能会劫持任何登录用户的会话，并嗅探该用户的会话 cookie。
如果您想要更高的安全性（不是 100%，但比之前的选项更高），请始终使用 https，对于所有资源（css、js、图像，而不仅仅是您的 php/html 文件），甚至通过以下方式提供登录页面https。
有关这些点的一些推理，请参阅 firesheep （针对劫持会话问题）或最近的 突尼斯语政府不会攻击突尼斯 facebook/yahoo/gmail 用户（甚至通过 https 提供登录页面）。
编辑：抱歉，我误解了你的问题。如果 SSL 域与非 ssl 域不同，您可能会遇到问题，因为会话 cookie 仅适用于相同的域或子域。因此，如果您登录并从 https://yourdomain.secure-server.com，浏览器只会将其发送回 yourdomain.secure-server.com（或 *.secure-server.com，如果您愿意），但不会发送回 yourdomain.com。我认为可以使通配符 cookie 对所有 *.com 子域都有效，但最好不要这样做（您希望将用户的会话 cookie 发送到 evil.com 吗？）
You don't need an iframe. Just make the action of the login form to point to https://yourdomain.com/login.php . In there you may check if user & password are correct, and then redirect again to plain http.
BUT this is not 100% secure. The fact that you are sending the user & password via https may prevent an attacker or sniffer to get that. But if you later revert to plain http, it is possible to this attacker/sniffer to hijack the session of any logged in user sniffing the session cookies of this user.
If you want more security (not 100%, but more than this previous option), stay always in https, for all resources (css, js, images too, not just your php/html files), and even serve the login page via https.
For some reasoning of these points, see firesheep (for the hijacking session problems) or the recent tunisian gov't attack on tunisian facebook/yahoo/gmail users (for serving even the login page via https).
edit: sorry, I misread your question. If the SSL domain is different than the not-ssl domain, you may have problems, as the session cookie only will work against the same domain or subdomains. So, if you do the login and send the session cookie from https://yourdomain.secure-server.com, it will only be sent back by the browser to yourdomain.secure-server.com (or *.secure-server.com if you will), but not to yourdomain.com. I think it's possible to make a wildcard cookie valid for all *.com subdomains, but it's better not to do this (do you want your users' session cookie be sent to evil.com ?)