建站
咨詢
售后
建站咨詢
新聞中心
大約十年前，F(xiàn)iresheep制造了一個大新聞。多年來，安全人員已經(jīng)了解了公共WiFi網(wǎng)絡(luò)的危害，但直到有人創(chuàng)建了這個用戶友好的Firefox擴展插件之后，這個安全問題才得到了人們的關(guān)注。從那時起，網(wǎng)絡(luò)上發(fā)生了很多事情，那么這樣的事情還有可能再發(fā)生嗎?
TL; DR; 由于HTTPS的存在，MITM攻擊目前不再是一個問題。但是，使用CORS，postMessage和其他一些很酷的東西，有時也可以繞過HTTPS。雖然這是網(wǎng)站所有者的錯，但受害的卻是用戶。
幾年前Firesheep是人們腦海中最重要的東西。在那個年代的網(wǎng)站，比如說Facebook，默認情況下還沒有開始使用HTTPS。移動設(shè)備(包括筆記本電腦和手機)的急劇增加使得連接到不受信任的WiFi網(wǎng)絡(luò)變得越來越普遍。
八年后的今天，這實際上不再是一個問題。這是由于HTTPS的廣泛采用，讓大量的網(wǎng)絡(luò)流量能夠被加密傳輸。就在上周，WIRED發(fā)表了一篇名為“ 關(guān)于使用酒店的Wi-Fi 你知道些什么?。來自你的設(shè)備的流量現(xiàn)在已被加密，即使有人發(fā)起MITM攻擊，你也不會受到什么太多的影響。這絕對是真的，當談?wù)摰桨踩詴r，你在酒店或咖啡店所提到的第一件事情就是MITM，但它已經(jīng)發(fā)生了很大的變化。
當你在假期旅行時，從機場到上飛機再到入住酒店，你可能會發(fā)現(xiàn)自己面臨著一個熟悉的困境：我真的要選擇信任這些隨機的公共Wi-Fi網(wǎng)絡(luò)嗎?就在幾年前，答案幾乎肯定是選擇不信任。但是在2018年，你的回答可能會有不同。
然而，即使網(wǎng)絡(luò)流量被加密了，但如果有人發(fā)起了MITM攻擊，仍然會發(fā)生很多不好的事情。可以從幾個角度出發(fā)討論這個話題。本文將重點介紹如何利用現(xiàn)代Web技術(shù)繼續(xù)發(fā)起MITM攻擊，以及網(wǎng)站所有者該如何阻止這種攻擊。
(WIRED發(fā)布的文章仍然有一個有效的觀點，但也有很大技術(shù)討論空間。)
攻擊場景的其余部分將基于下面的一些條件
你正在酒店過夜，并將你的設(shè)備連接到酒店的WiFi。由于你處于不受信任的網(wǎng)絡(luò)中，因此你可能不會去瀏覽任何敏感的信息。
但是，你正在使用與往常相同的瀏覽器會話。出于方便，人們永遠不會退出Facebook或他們的工作電子郵件。
HSTS和cookie標志
我們需要從一些有關(guān)HSTS的基本信息開始。
HSTS是一個HTTP標頭，它指示瀏覽器后續(xù)只應(yīng)嘗試通過HTTPS的方式加載該頁面。從瀏覽器第一次訪問具有此標頭的網(wǎng)站時，它會將域名添加到列表中，并在標頭中指定的時間內(nèi)記住它。即使我明確的寫了http://網(wǎng)頁瀏覽器也會直接通過HTTPS發(fā)送請求。
也可以添加一個標志來預(yù)先加載標頭。當Web瀏覽器獲取更新或下載時，會包含預(yù)加載的域名列表。Web瀏覽器將拒絕向這些域名發(fā)送HTTP流量，即使用戶第一次訪問這些站點也是如此。
HSTS的另一個重要特性是名為includeSubDomains的標志。如果https://example.com包含此標頭，則Web瀏覽器將拒絕發(fā)送任何未加密的流量到http://foo.example.com。
HSTS標頭只能在HTTPS請求中設(shè)置。根據(jù)規(guī)范，這個標頭在HTTP請求上應(yīng)該是不起作用的(實際上沒有經(jīng)過足夠多的瀏覽器測試來確定這一點)。當人們按以下順序進行重定向時，這會導(dǎo)致一個常見問題：
http://example.com>
http://www.example.com>
https://www.example.com
由于第一個HTTPS請求將轉(zhuǎn)到www. 因此includeSubDomains-flag并不起作用的，因為必須在apex域名上設(shè)置。
最后，還需要提到的一個東西是安全標志(secure)。這是在創(chuàng)建cookie時在cookie上設(shè)置的標志。設(shè)置此標志后，將永遠不會通過HTTP發(fā)送cookie。如果向http://example.com發(fā)出請求則響應(yīng)看起來像是用戶沒有保存的cookie一樣。
CORS
我們之前在這里已經(jīng)提到過一些關(guān)于CORS常見的錯誤配置。如果你還沒有正確配置，那么我建議你先閱讀那篇文章。
最簡單的攻擊方式是壓根兒不使用HSTS。假設(shè)CORS已經(jīng)啟用，那么http://example.com可以請求https://example.com并讀取數(shù)據(jù)。這在MITM場景中是可能發(fā)生的，因為發(fā)出請求的那個請求是通過HTTP托管的。由于實際的請求將通過HTTPS發(fā)送，因此即使帶有secure標志的cookie也會隨之發(fā)送。
另一個非常常見的問題是CORS允許訪問任何子域名，但HSTS沒有設(shè)置includeSubDomains-標志。這意味著攻擊者能夠在http://foobar.example.com上托管惡意的javascript然后向https://example.com發(fā)出請求。在MITM攻擊場景中，攻擊者可以隨意構(gòu)造他們想攻擊的任何子域名。在討論HSTS時，我們在前面已經(jīng)解釋過，它存在一個重定向問題，因此當主應(yīng)用程序托管在www上時，這種攻擊手法就很常見的。
一個有趣的攻擊向量是在使用HSTS時，CORS可以支持多個域名。我們用一個真實的案例來說明一下，在periscope.tv上的CORS可以通過HTTP和HTTPS接受*.periscope.tv，*.pscp.tv和*.twitter.com。只要有人登錄到periscope.tv，HSTS就會確保后續(xù)的請求不會通過HTTP發(fā)送到該域名。但是，受害者之前從未訪問過*.pscp.tv的可能性很大，而且在MITM攻擊場景中，攻擊者可以在那里偽造一個HTTP的頁面并發(fā)送請求到periscope.tv。在這種情況下，這種攻擊將被阻止，因為所有這些域名的所有HSTS策略都是預(yù)加載的。
postMessage
正如我們之前所述，在使用postMessage時檢查消息的來源非常重要。但是，這些檢查僅檢查來源是否以特定內(nèi)容作為結(jié)尾并因此導(dǎo)致攻擊者可以匹配任何子域名，這是個很常見的問題。這意味著完全沒有檢查協(xié)議。任何子域名上的HTTP頁面都能夠?qū)⑾l(fā)送到主應(yīng)用程序。
還有一些基于正則表達式的來源檢查，有意允許了HTTP和HTTPS，即使Web應(yīng)用程序應(yīng)該只能通過HTTPS使用也會允許匹配HTTP。還應(yīng)該注意的是，有幾種網(wǎng)絡(luò)協(xié)議實際上也可以托管Web內(nèi)容，例如FTP。因此，務(wù)必確保將HTTPS列入了白名單，而不是將HTTP列入黑名單。相關(guān)案例請查看：https://hackerone.com/reports/210654
至于與HSTS的組合使用，實際上與CORS的問題遵循的是相同的原則。
WebSocket
WebSocket實際上在握手請求中共享了cookie，因此需要用與CORS請求相似的方式進行源的檢查。這僅在應(yīng)用程序需要關(guān)注cookie數(shù)據(jù)時才很重要，因此并不總是適用于很多情況。
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
可能已經(jīng)有一些類似的方式或技術(shù)以上述類似的方式被濫用。如果今天沒有，那很快就會有。如果MITM在你的威脅模型中，那么這些都是不應(yīng)忽視的問題。
修復(fù)建議
網(wǎng)站所有者
HSTS
第一步是在網(wǎng)站上開始使用HSTS，因為今天許多人都沒有這樣做。在已經(jīng)通過HTTPS提供服務(wù)的網(wǎng)站上，這樣做沒有任何問題。當你實現(xiàn)了HSTS并確保它正常工作時，記得添加關(guān)于預(yù)加載它的標志。
如果可能，請在HTTP頭中包含includeSubDomains-header。但是，這將要求所有子域名也要通過HTTPS提供所有流量，不過這取決于具體情況并且可能有點困難。
CORS
確保CORS僅接受HTTPS請求。因為最常見的解決方案是反射源，即使源與模式匹配成功，也需要檢查它是否https://開頭。
postMessage和WebSocket
與CORS非常相似：確保檢查了源并檢查了協(xié)議而不僅僅是主機名。
普通用戶
在寫這篇文章之前，我曾與幾個有這些安全問題的大網(wǎng)站的安全人員聯(lián)系過。雖然許多人都比較關(guān)心這個問題，但也有幾個人認為這是可以接受的風險。他們認為受害者不太可能受到這樣的MITM攻擊或類似的理由。因此，盡管應(yīng)該由網(wǎng)站所有者負責修復(fù)，但用戶也必須關(guān)心這個問題。
· 第一步是安裝HTTPS Everywhere。它是一個瀏覽器插件，類似于HSTS，但是在客戶端上。
· 第二個建議是不要使用公共WiFi。自Firesheep時代以來的最大變化也是移動數(shù)據(jù)的價值的變化。許多經(jīng)常連接到開放網(wǎng)絡(luò)的人也會用手機連接這些開放式網(wǎng)絡(luò)。
· 如果上面一條不適用于你，那第二個最好的建議是使用VPN。但是，應(yīng)該明白的是，這也不是一種防御策略。由于許多公共熱點在你連接時都有某種登錄頁面，因此你實際上必須連接到網(wǎng)絡(luò)一段時間，而不會有流量通過VPN。在此期間，熱點會強制你的設(shè)備發(fā)出前文所描述的技術(shù)的網(wǎng)絡(luò)請求。
...
讓我再次引用WIRED文章作為本文所有內(nèi)容的結(jié)束。請記住，要對自己的情況進行風險分析，然后采取行動。
本文標題：無視HTTPS發(fā)起中間人攻擊
文章出自：http://m.fisionsoft.com.cn/article/ccsepdd.html
