這個答案主要是關於克里斯·迪克森(Chris Dixon)的聲明,而不是回答“有多少攻擊來自MiTM”。
如果我們斷言可能成為MiTM的方式和給定的後果,我認為我們可以對我們是否關心MiTM攻擊的流行程度做出一些結論。
如果我們考慮不同情況下的某些風險,我們可能會遇到以下問題:
- 有人通過利用Web應用程序本身來竊取數據庫嗎?
- 有人會通過MiTM攻擊來攻擊用戶/管理員
我想說(通常)前者的影響要大得多,應該從很多方面減輕最大的負擔,並對待第一個。
因此,要使第2點勝過第1點,我認為MiTM真的必須瘋狂地將其視為與第1點一樣高的安全障礙(正如Chris在引文中所指出的那樣)!
現在,如果我們看到不同的攻擊媒介。 MiTM的第一個。要成為MiTM,可以例如:
- 擁有一個惡意無線接入點。這是微不足道的,但是對於有針對性的攻擊,您必須使用您的Web應用程序將其置於受害者的同一個物理位置。
- 嗅探未加密的無線數據或通過HUB傳入的數據(它們甚至已經存在了嗎?)
- 使用ARP中毒來攻擊用戶。除非您與使用您的Web應用程序的目標用戶位於同一網絡上,否則這並非易事。
- DNS緩存中毒。為此,您需要對目標用戶正在使用的DNS進行毒害。如果DNS設置不正確,則執行此攻擊將變得微不足道,但是,要使此方法起作用,必須依靠很多手段。
- 網絡釣魚攻擊。這些仍然愚弄了毫無戒心和天真的用戶,但是用戶承擔了很多責任。
所有這些僅攻擊一個或一小部分用戶。即使那樣,攻擊這些用戶也會在他們的瀏覽器中向他們發出警告(也有攻擊的方法,但是我在這裡不做說明)。僅通過破壞根CA或發現用於生成證書的算法中的缺陷,您才可以冒充為受信任的證書頒發者。
另一方面,如果我們查看所有潛在的討厭問題,我們可以看到的東西,如果我們沒有對Web應用程序本身進行足夠的安全性投資,我們會看到類似以下的攻擊媒介:
- SQL注入-瑣碎且易於利用和發現。極高的傷害影響。
- XSS(跨站點腳本)-易於發現,更難以利用。我認為今後我們會看到越來越多的用戶影響。我可以預見,這將成為我們過去一直看到的“新SQL注入”趨勢。
- CSRF(跨站點請求偽造)-中等發現,中等利用。這將要求用戶導航到一個已經擁有的站點,從而觸發對您的webapp的請求,該請求將代表用戶進行交易。
因此,僅需提及攻擊網絡應用程序並成為MiTM的少數幾個但很流行的方法,我就可以將其留給您要保護的特定組織的特定風險/後果分析,您是否應該通過實施SSL或通過整體保護Web應用程序(還包括知識產權,用戶數據,敏感數據,可能破壞其他應用程序的潛在數據等等)直接保護用戶。
所以,以我的拙見,我非常同意克里斯·迪克森的說法。在開始考慮保護傳輸層之前,請盡可能優先考慮保護Web應用程序的安全。
修改:
附帶一提:Firesheep喚醒後,Facebook,Gmail等頁面受到嚴重的MiTM攻擊。這只能通過SSL和認知來緩解。
但是,如果考慮一下,使用Firesheep嗅探無線流量並劫持會話將要求您連接的無線局域網沒有任何加密。
今天我開車去開車時,它大大減少了開放無線AP的數量,也大大減少了啟用WEP的AP的數量。我們一直看到越來越多的WPA2加密AP在大多數情況下為我們提供了足夠的安全性。
現在,有人創建一個簡單易用的工具來嗅探和劫持用戶會話的風險是什麼?對這些用戶有什麼影響?也可以通過不同的方式來緩解這種情況(當來自不同足蹟的用戶同時進行身份驗證,出現問題時通知用戶(gmail是一個很好的例子)。