大約十年前，Firesheep制造了一個大新聞。多年來，安全人員已經了解了公共WiFi網絡的危害，但直到有人創建了這個用戶友好的Firefox擴展插件之后，這個安全問題才得到了人們的關注。從那時起，網絡上發生了很多事情，那么這樣的事情還有可能再發生嗎?

TL; DR; 由于HTTPS的存在，MITM攻擊目前不再是一個問題。但是，使用CORS，postMessage和其他一些很酷的東西，有時也可以繞過HTTPS。雖然這是網站所有者的錯，但受害的卻是用戶。

幾年前Firesheep是人們腦海中最重要的東西。在那個年代的網站，比如說Facebook，默認情況下還沒有開始使用HTTPS。移動設備(包括筆記本電腦和手機)的急劇增加使得連接到不受信任的WiFi網絡變得越來越普遍。

[[256498]]

八年后的今天，這實際上不再是一個問題。這是由于HTTPS的廣泛采用，讓大量的網絡流量能夠被加密傳輸。就在上周，WIRED發表了一篇名為“ 關于使用酒店的Wi-Fi 你知道些什么?。來自你的設備的流量現在已被加密，即使有人發起MITM攻擊，你也不會受到什么太多的影響。這絕對是真的，當談論到安全性時，你在酒店或咖啡店所提到的第一件事情就是MITM，但它已經發生了很大的變化。

當你在假期旅行時，從機場到上飛機再到入住酒店，你可能會發現自己面臨著一個熟悉的困境：我真的要選擇信任這些隨機的公共Wi-Fi網絡嗎?就在幾年前，答案幾乎肯定是選擇不信任。但是在2018年，你的回答可能會有不同。

然而，即使網絡流量被加密了，但如果有人發起了MITM攻擊，仍然會發生很多不好的事情。可以從幾個角度出發討論這個話題。本文將重點介紹如何利用現代Web技術繼續發起MITM攻擊，以及網站所有者該如何阻止這種攻擊。

(WIRED發布的文章仍然有一個有效的觀點，但也有很大技術討論空間。)

攻擊場景的其余部分將基于下面的一些條件

你正在酒店過夜，并將你的設備連接到酒店的WiFi。由于你處于不受信任的網絡中，因此你可能不會去瀏覽任何敏感的信息。

但是，你正在使用與往常相同的瀏覽器會話。出于方便，人們永遠不會退出Facebook或他們的工作電子郵件。

HSTS和cookie標志

我們需要從一些有關HSTS的基本信息開始。

HSTS是一個HTTP標頭，它指示瀏覽器后續只應嘗試通過HTTPS的方式加載該頁面。從瀏覽器第一次訪問具有此標頭的網站時，它會將域名添加到列表中，并在標頭中指定的時間內記住它。即使我明確的寫了http://網頁瀏覽器也會直接通過HTTPS發送請求。

也可以添加一個標志來預先加載標頭。當Web瀏覽器獲取更新或下載時，會包含預加載的域名列表。Web瀏覽器將拒絕向這些域名發送HTTP流量，即使用戶第一次訪問這些站點也是如此。

HSTS的另一個重要特性是名為includeSubDomains的標志。如果https://example.com包含此標頭，則Web瀏覽器將拒絕發送任何未加密的流量到http://foo.example.com。

HSTS標頭只能在HTTPS請求中設置。根據規范，這個標頭在HTTP請求上應該是不起作用的(實際上沒有經過足夠多的瀏覽器測試來確定這一點)。當人們按以下順序進行重定向時，這會導致一個常見問題：

http://example.com>

http://www.example.com>

https://www.example.com

由于第一個HTTPS請求將轉到www. 因此includeSubDomains-flag并不起作用的，因為必須在apex域名上設置。

最后，還需要提到的一個東西是安全標志(secure)。這是在創建cookie時在cookie上設置的標志。設置此標志后，將永遠不會通過HTTP發送cookie。如果向http://example.com發出請求則響應看起來像是用戶沒有保存的cookie一樣。

CORS

我們之前在這里已經提到過一些關于CORS常見的錯誤配置。如果你還沒有正確配置，那么我建議你先閱讀那篇文章。

最簡單的攻擊方式是壓根兒不使用HSTS。假設CORS已經啟用，那么http://example.com可以請求https://example.com并讀取數據。這在MITM場景中是可能發生的，因為發出請求的那個請求是通過HTTP托管的。由于實際的請求將通過HTTPS發送，因此即使帶有secure標志的cookie也會隨之發送。

另一個非常常見的問題是CORS允許訪問任何子域名，但HSTS沒有設置includeSubDomains-標志。這意味著攻擊者能夠在http://foobar.example.com上托管惡意的javascript然后向https://example.com發出請求。在MITM攻擊場景中，攻擊者可以隨意構造他們想攻擊的任何子域名。在討論HSTS時，我們在前面已經解釋過，它存在一個重定向問題，因此當主應用程序托管在www上時，這種攻擊手法就很常見的。

一個有趣的攻擊向量是在使用HSTS時，CORS可以支持多個域名。我們用一個真實的案例來說明一下，在periscope.tv上的CORS可以通過HTTP和HTTPS接受*.periscope.tv，*.pscp.tv和*.twitter.com。只要有人登錄到periscope.tv，HSTS就會確保后續的請求不會通過HTTP發送到該域名。但是，受害者之前從未訪問過*.pscp.tv的可能性很大，而且在MITM攻擊場景中，攻擊者可以在那里偽造一個HTTP的頁面并發送請求到periscope.tv。在這種情況下，這種攻擊將被阻止，因為所有這些域名的所有HSTS策略都是預加載的。

postMessage

正如我們之前所述，在使用postMessage時檢查消息的來源非常重要。但是，這些檢查僅檢查來源是否以特定內容作為結尾并因此導致攻擊者可以匹配任何子域名，這是個很常見的問題。這意味著完全沒有檢查協議。任何子域名上的HTTP頁面都能夠將消息發送到主應用程序。

還有一些基于正則表達式的來源檢查，有意允許了HTTP和HTTPS，即使Web應用程序應該只能通過HTTPS使用也會允許匹配HTTP。還應該注意的是，有幾種網絡協議實際上也可以托管Web內容，例如FTP。因此，務必確保將HTTPS列入了白名單，而不是將HTTP列入黑名單。相關案例請查看：https://hackerone.com/reports/210654

至于與HSTS的組合使用，實際上與CORS的問題遵循的是相同的原則。

WebSocket

WebSocket實際上在握手請求中共享了cookie，因此需要用與CORS請求相似的方式進行源的檢查。這僅在應用程序需要關注cookie數據時才很重要，因此并不總是適用于很多情況。

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

可能已經有一些類似的方式或技術以上述類似的方式被濫用。如果今天沒有，那很快就會有。如果MITM在你的威脅模型中，那么這些都是不應忽視的問題。

修復建議

網站所有者

HSTS

第一步是在網站上開始使用HSTS，因為今天許多人都沒有這樣做。在已經通過HTTPS提供服務的網站上，這樣做沒有任何問題。當你實現了HSTS并確保它正常工作時，記得添加關于預加載它的標志。

如果可能，請在HTTP頭中包含includeSubDomains-header。但是，這將要求所有子域名也要通過HTTPS提供所有流量，不過這取決于具體情況并且可能有點困難。

CORS

確保CORS僅接受HTTPS請求。因為最常見的解決方案是反射源，即使源與模式匹配成功，也需要檢查它是否https://開頭。

postMessage和WebSocket

與CORS非常相似：確保檢查了源并檢查了協議而不僅僅是主機名。

普通用戶

在寫這篇文章之前，我曾與幾個有這些安全問題的大網站的安全人員聯系過。雖然許多人都比較關心這個問題，但也有幾個人認為這是可以接受的風險。他們認為受害者不太可能受到這樣的MITM攻擊或類似的理由。因此，盡管應該由網站所有者負責修復，但用戶也必須關心這個問題。

· 第一步是安裝HTTPS Everywhere。它是一個瀏覽器插件，類似于HSTS，但是在客戶端上。

· 第二個建議是不要使用公共WiFi。自Firesheep時代以來的最大變化也是移動數據的價值的變化。許多經常連接到開放網絡的人也會用手機連接這些開放式網絡。

· 如果上面一條不適用于你，那第二個最好的建議是使用VPN。但是，應該明白的是，這也不是一種防御策略。由于許多公共熱點在你連接時都有某種登錄頁面，因此你實際上必須連接到網絡一段時間，而不會有流量通過VPN。在此期間，熱點會強制你的設備發出前文所描述的技術的網絡請求。

...

讓我再次引用WIRED文章作為本文所有內容的結束。請記住，要對自己的情況進行風險分析，然后采取行動。