HSTS vs只有https和安全cookie

Question

如果我的網站使用安全會話cookie在https上提供服務並將任何針對http url的嘗試重定向到https，是否足夠好？

什麼樣的安全漏洞可以在這個設置中暴露給我，因爲我不能在沒有設置HSTS頭的情況下生存？

Answer 1

該策略通過使攻擊者難以誘騙用戶使用SSL以外的內容訪問您的站點來防止被動竊聽。它也可能確保用戶存儲的任何書籤都將指向https網址，這很好。然而，在發生中間人攻擊時，HSTS仍然具有優勢。

HSTS試圖解決的問題的核心是瀏覽器不知道給定站點是否應該使用SSL。而大多數用戶並沒有明確嘗試使用SSL;如果他們輸入一個URL，他們通常首先進入非SSL http站點，通常他們只是跟隨鏈接。如果攻擊者可以誘騙用戶通過http URL訪問您的網站，並且可以坐在用戶流量的中間（例如通過他們的無線AP），那麼攻擊者可以發起中間人攻擊通過代理用戶的流量到您的網站並將網站呈現給用戶而不使用SSL（這是一種降級攻擊），從而針對您的網站。由於用戶不會看到SSL，因此他們的瀏覽器不會識別出攻擊者沒有爲您的網站提供有效的證書，並且他們沒有直接連接到您的網站。 （更復雜的方法是攔截SSL流量併爲您的站點提供自簽名或其他無效證書，但這通常會導致瀏覽器警告。）

在這種情況下，將非SSL用戶重定向到SSL或在Cookie上設置安全標誌實際上並不能幫助您。中間人攻擊者將連接到您的SSL站點（並將用戶的行爲代理到該站點），並在將它們傳遞給用戶時從Cookie中移除安全標誌。

攻擊者當然也可以刪除HSTS報頭。但是，HSTS協議的要點是，如果用戶過去成功直接進入您的網站，他們的瀏覽器將記住您的網站發送了HSTS。如果他們以後連接到您的網站並發現它沒有使用SSL或者瀏覽器無法驗證證書，則瀏覽器會拋出錯誤並拒絕繼續。如果瀏覽器支持HSTS並將您的站點記錄爲需要SSL，這將防止攻擊者將您的站點降級爲非SSL。

維基百科有fairly good discussion of this，我認爲這比the RFC中的討論要清楚些。