多位安全專家過去曾表示，登錄頁面應該位於ssl https上。那麼，如果我的登錄是在所有頁面上顯示的塊，該怎麼辦？這是否意味着我的整個網站必須是https？必須登錄成爲https頁面
我讀過它可以將表單放在http上，但將其發佈到https，但我讀過一個人說，它可以被中間人攻擊中的一個人利用。有人能證實這一點嗎？我有一個100點的獎勵給可以證實這一點的人（並幫助我解決這個問題的實際答案）。我的登錄表單位於每個頁面上，是否需要在https上創建整個網站？請隨時質疑我在這裏所說的任何內容。他們只是我閱讀過的東西，但沒有經驗，也沒有親自嘗試。
編輯：對於那些問我，當我發佈這個問題時，我試圖設置賞金，但系統不會讓我。我查看了常見問題解答，並看到可以在發佈問題2天后發佈賞金。這就是爲什麼你看不到賞金。但是我不會選擇一個答案，直到我在2天內設置了獎勵。對不起，有任何困惑。
我讀過它可以將表單放在http上，但將其發佈到https，但我讀過一個人說，它可以在中間人攻擊中被利用。有人能證實這一點嗎？
是的。表單通過HTTP提供，因此中間的人可以對其進行更改（例如，它在表單提交之前將憑證發送到自己的服務器）。
一個實際的答案如何安全地解決此
如果安全真的很重要 - 使用HTTPS整個站點。即使密碼已經發送，如果你回到HTTP然後cookie可以被盜（見Firesheep）
如果安全性不重要，那麼不要把登錄表單放在每一頁上。只需鏈接到登錄頁面即可。
大約一個小時前還有另一個答案，但我猜所有者因爲投票而將其刪除。他在說，Facebook使用http作爲主頁面，但將表單發佈到https，就像我在問這個問題一樣。我檢查了他們的代碼，確實他們做了`https：// login.facebook.com/login.php`所以..有沒有我們想念的東西，或者他們在這裏撥錯了電話？我只是想知道，因爲Facebook是大狗，如果它確實沒有安全感，他們應該知道這些東西？任何意見？ – sami 2010-11-30 00:52:22
如果你希望你的數據安全，你必須在整個網站上使用SSL（認證）。但是您不需要使用SSL來保證您的密碼安全。例如，您可以使用openID，臉書連接，twitter登錄爲您處理這部分。這樣一來，密碼就不會通過純文本的方式發送出去。
簡單回答 「是」 的網站的登錄頁面，其餘的應該通過SSL提供
這裏就是爲什麼SSL實施常見問題解答：
我讀過它可以將表單放在http上但將其發佈到https，但我閱讀某人說，它可以被中間人攻擊中的一個人利用。
否<form>的目標是由瀏覽器在使用中執行的全新呼叫。
如果URL http://example.com/被訪問和網頁的內容已被瀏覽器渲染，不安全的連接被關閉（是的，它可以保持打開[保持活動。但對於URL請求是完成）。
對於網站的登錄目標https://example.com/的SSL會話將服務器和客戶端之間使用不同的服務器端口（通常爲443），並且沒有由現有的頁數據（可能除了「參照」）被用來進行協商/之後發送安全連接已建立。
我讀過它可以將表單放在http上，但將其發佈到https，但我讀過一個人說它可以在中間人攻擊中被一個人利用。有人能證實這一點嗎？
是的。表單通過HTTP提供，因此中間的人可以對其進行更改（例如，它在表單提交之前將憑證發送到自己的服務器）。
在被攻破的網站也沒關係，內容是否已送達可靠與否。一個網站的內容可以通過SSL傳遞，但代碼仍然可能被泄露。
此外，cookie可能被盜。但他們只是文字。這就是你的網站所做的，「文本」是重要的。如果你依賴於「瀏覽器」告訴你的腳本，你的應用程序是不安全的。使用cookie驗證（基於IP，基於瀏覽器，無論基於什麼），因此cookie不能「被盜」。
每當用戶發送數據時使用SSL安全的網站，即值得保護。評論博客文章是不是一件事我會強調我的服務器與建立一個SSL連接...
即使你試圖把登錄塊放在一個使用https的iframe中，一個男人在中間攻擊可能會輕易改變iframe的src，因此您可以使登錄框成爲登錄鏈接（使用https登錄頁面），或者您需要更多資源才能使用ssl爲具有登錄框的所有網頁運行您的網站...
那麼，如果你不使用SSL進行登錄，那麼用戶的密碼可能會泄露給任何有意收聽客戶端 - 服務器通信（基本上是讀取數據流）的人。 （這是不好的^^）
正如上面的goreSplatter所說，您可以很容易地將表單目標設置爲安全端點（即https://site.com/login），並且將使用安全連接來發送用戶憑證和接收響應。
然後，大多數網站繼續通過基本的HTTP進行通信，這隻會「使」用戶面臨會話劫持風險（中間人讀取其會話標識符/簽名/隨機數/任何內容，然後假裝爲經過身份驗證的客戶端，因此如果他成功了，他可以操縱客戶端的受保護資源，但此方法不允許「竊取整個帳戶」）。這通常被認爲是次要威脅，並且由於與SSL通信相關的開銷，所有請求的安全連接僅用於關鍵應用程序（例如網上銀行）。
最後，回答你的問題：不，只有在傳送敏感數據的地方纔必須保證安全。
您是否可以重新設計UI概念？理念：在每個頁面上都有信息登錄UI，但不是實際的登錄控制。您的新信息控制將列出：根據國家
Logged In As <user_name>或Not Logged InLogin或Logout鏈接，然後的鏈接會顯示登錄彈出，其內容完全是安全網頁。
這種方法可以讓你接近你已經擁有的東西（每個頁面上的一些登錄功能），但是路由/分層的方式是你的身份驗證完全通過SSL進行安全保護。
例如，GMAIL在您可以啓用SSL的配置中有一個選項。 Facebook，Twitter和所有社交媒體都沒有SSL或未啓用。
我認爲如果您真的希望您的網站從所有惡意（bot或不）的安全性更好地使用SSL。 （但如果啓用了SSL，則有被劫持的風險）否則，您可以嘗試使用js硬編碼混淆表單數據。
上面的很好的答案，再加上一切，並得到你自己的想法關於此事！
祝你好運。
我沒有看到75點獎勵。 – Reinderien 2010-11-29 23:40:36
問題是6分鐘的時候，一個賞金不能添加（現在提供一個爲時過早）。 – Quentin 2010-11-29 23:44:44
我們都知道答案，但是你的賞金聲明讓我們無法回答:) – Michael 2010-11-29 23:45:08