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中的用戶身份驗證

回答

相關問題