SSL iframe中的用户身份验证

我的web应用程序受到越来越多的关注，我需要提供额外的安全措施来保护我的客户。SSL iframe中的用户身份验证

我看到的最大问题是用户登录数据以纯文本的形式发送。我的这个问题的目标是辨别下列方法是否有改进。

在扩展中，我将需要为我的服务获得专用服务器。这个建议的解决方案是暂时的。

我目前在共享托管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与来自数据库的密码（散列+（每用户基于随机腌制））进行身份验证。
正确的会话重新生成后，设置验证身份验证的会话。
本届会议是然后以某种方式转移和http://mydomain.com

验证是这种方法甚至有可能实现吗？这是否会改善我的登录安全性，或只是将攻击者的“密码截取点”移至另一个实例？

所有的反馈表示赞赏。

来源

2011-05-10 Mattis

你不需要一个iframe。只需将登录表单的操作指向https://yourdomain.com/login.php即可。在那里你可以检查用户&密码是否正确，然后再次重定向到普通的http。

但是这不是100％安全的。您通过https发送用户密码的事实可能会阻止攻击者或嗅探器获取该密码。但是如果您稍后恢复为普通http，则此攻击者/嗅探器可以劫持任何登录用户的会话，嗅探此用户的会话Cookie。

如果你想要更多的安全性（不是100％，但比以前的选择更多），始终保持在https中，对于所有资源（css，js，图片也不只是你的php/html文件）通过https登录页面。

对于这些要点的某些推理，请参阅firesheep（针对劫持会话问题）或最近tunisian gov't attack突尼斯facebook/yahoo/gmail用户（通过https服务甚至登录页面）。

编辑：对不起，我误解了您的问题。如果SSL域与not-ssl域不同，那么您可能会遇到问题，因为会话cookie只能针对相同的域或子域工作。因此，如果您进行登录并从https://yourdomain.secure-server.com发送会话cookie，它将只会被浏览器发送回yourdomain.secure-server.com（或* .secure-server.com，如果您愿意的话），但不会发送给yourdomain .COM。我认为有可能为所有* .com子域名创建一个通配符cookie，但最好不要这样做（您是否希望将用户的会话cookie发送给evil.com？）

来源

2011-05-10 14:01:35

写得不错。切换回HTTP可以保护密码，但不保护要用密码保护的会话数据。 – martinstoeckli 2011-05-10 14:45:05

谢谢Carlos。根据这篇文章，我正在计划努力使会话更加困难：http://stackoverflow.com/questions/5081025/php-session-fixation-hijacking。但是，我还计划将会话cookie发送给evil.com和mischief.net。 – Mattis 2011-05-10 14:56:04

“...甚至通过https服务登录页面”？如果您想要任何安全性，您*必须*通过https提供登录表单。拦截登录表单并插入MITM攻击是微不足道的。通过http渲染一个登录页面只会让你错误地认识到已经完成了一些安全的事情。请参阅：http：//www.thoughtcrime.org/software/sslstrip/ – 2011-05-13 19:57:25

SSL iframe中的用户身份验证

回答

相关问题