萬物互聯時代，無線網絡全面覆蓋我們的生活，基本上各家門店都有wifi標志，而且有的還沒有密碼，蹭WiFi似乎已成為一項基本“生存技能”，現代人的基本狀態就像下面這首打油詩一樣：

枯藤老樹昏鴉，空調Wifi西瓜

葛優同款沙發，我就往那一趴

如果企業沒有對自家應用做好數據防護，蹭網的同時，用戶個人隱私也暴露在互聯網中，不安全協議傳輸數據，直接導致用戶數據被中間人劫持獲取。

同時，流量被劫持獲取，可以直接對服務器發起攻擊，獲取服務器業務數據、用戶數據等核心資產信息。那么企業應該如何去避免此類攻擊的發生呢？首先得去了解一下中間人攻擊的前因后果。

中間人攻擊的前因后果

協議先天性缺陷

（1）HTTP明文傳輸導致用戶信息泄露？

從攻擊的視頻中可以知道，攻擊者是實施了HTTP協議的中間人攻擊，相信每個計算機行業人員都知道，超文本傳輸協議（HTTP，HyperText TranSfer Protocol）是互聯網上應用最為廣泛的一種網絡協議，所有的WWW文件都必須遵守這個標準，也就是說萬維網不得不使用這個協議，也是非常的尷尬。

從攻擊者的角度是怎么看待這個問題呢？

尋找一個采用HTTP協議傳輸數據的網站系統，這里針對用戶登錄的賬號信息進行數據獲取，使用WireShark流量分析工具對局域網下的用戶HTTP數據包進捕獲，參考下圖：

對TCP數據流進行數據分析，可以發現，存在明文的用戶名uname和密碼password，參考下圖：

總結：由此可見HTTP數據流是用明文方式傳輸數據，攻擊者可以利用局域網抓包等手段輕易獲取用戶與服務器的交互信息。?

（2）為什么HTTP是明文傳輸？

從上一小節可以知道攻擊者抓取的HTTP數據包里面的數據是明文，為了解明文傳輸的原理，可以先了解以下在OSI七層模型中HTTP協議工作的地方，OSI模型七個層次的功能以及協議集圖示如下：

根據OSI七層模型，可以知道HTTP協議工作在應用層，再來看看HTTP數據包的封裝過程，發送方在客戶端頁面輸入上層數據，上層數據到傳輸層會添加TCP報頭形成數據段，再下送到網絡層添加IP報頭形成數據段，在繼續下送至數據鏈路層添加以太網首部和尾部，形成以太網幀，最后傳遞至物理層形成01010形式的比特流，整個過程，上層數據這一部分沒有進行任何加密數據處理，參考下圖：

同理接收方也是如此，接受方收到二進制比特流，通過層層上送解包，最終獲取明文的上層數據，參考下圖：

總結：HTTP雖然是應用層的協議，但是其數據在整個數據裝包中都是處于明文狀態，只是不同層次之間進行了包的封裝轉換，在不同層次會看到不同的數據，比如在物理層，只能看到0101010類型的二進制比特流，但是在應用層卻可以看到明文的數據，整個過程只是一個數據包的封裝和解包，沒有設計數據的加密和解密操作。

（3）中間人攻擊的根源是什么？

通過了解HTTP明文傳輸的分析過后，結合OSI七層模型每一層的含義，參考如下：

路由器是存在于OSI七層模型的網絡層，也就是通常接觸最多的局域網，家里接入有線或者無線網絡都會設置路由器，用戶通過接入路由器與外界網絡進行聯系。

中間人攻擊也是在這一層面實施攻擊的，這一層存在的協議參考OSI七層模型可以知道有IP，ARP，ICMP等協議。在路由器層面，也就是局域網內是通過地址解析協議即ARP（AddreSS ReSolution Protocol），根據IP地址獲取物理地址進行目標尋址交流。大概的流程內容如下：

• 主機發送信息時將包含目標IP地址的ARP請求廣播到網絡上的所有主機，并接收返回消息，以此確定目標的物理地址；

• 收到返回消息后將該IP地址和物理地址存入本機ARP緩存中并保留一定時間，下次請求時直接查詢ARP緩存以節約資源。

ARP協議沒有安全認證機制，因為局域網內主機是建立在信任的基礎上的，所以只要主機接收到ARP應答包，都會緩存在ARP表中，這就為ARP欺騙提供了可能。攻擊者可以發送錯誤的IP地址MAC地址的映射關系。

ARP欺騙主機等攻擊是最常見的中間人攻擊，在同一個局域網中，通過將網卡設置為混雜模式，借助ARP欺騙實現中間人攻擊即可監聽目標設備的網絡通信。ARP攻擊原理如下圖：

主機A IP:192.168.1.2 MAC:02-02-02-02-02-02

主機B IP:192.168.1.3 MAC:03-03-03-03-03-03

網關 IP:192.168.1.1 MAC:01-01-01-01-01-01

主機B為攻擊者，向被攻擊者主機A不斷發送ARP響應數據包內容：IP：192.168.1.1對應MAC：03-03-03-03-03-03 向網關不斷發送ARP響應包內容：192.168.1.2對應MAC：03-03-03-03-03-03，在局域網內，廣播尋址是根據MAC地址來定位用戶地址的，所以，一旦mac地址進行了改變，用戶地址也就進行了改變，由于ARP會更新緩存表的特性，導致了攻擊者可以通過不斷發送ARP響應包達到欺騙網關和被攻擊者的目的，代替用戶與網關進行信息交互，同時代替網關與用戶聯系，進而形成了中間人攻擊。

總結：ARP緩存接受任何時間更新成為中間人攻擊的根本原因

安全協議不安全

（1）HTTPS加密傳輸也存在信息泄漏？

開發人員針對部分不安全協議進行了安全控制，采用HTTP+SSL的方式進行數據傳輸，也就是我們常說的HTTPS協議。使用安全套接字層（SSL）進行信息交換，簡單來說就是HTTP的安全版，來保證傳輸的數據安全。

從攻擊者的角度是怎么看待這個問題呢？

可以通過實驗來看結果，選擇QQ郵箱登錄網站，該網站使用HTTPS，使用WireShark抓包查看TCP數據量

追蹤TCP數據流，數據全是亂碼，無法識別數據，很明顯數據已經被加密了，通過抓包并沒有獲取用戶信息。

到這里一定會存在一個疑問，如果我的App與服務器全部采用HTTPS通信不就沒有中間人攻擊的問題了嗎？

事實上如果用自己偽造的CA證書去加解密數據包，一樣可以獲取到敏感信息，大致攻擊思路：攻擊者在設備上導入并信任自己的CA證書，然后利用該證書進行數據的加密和解密，在這個過程中，明文信息已經被暴露在攻擊者面前。

比如這里，將CA證書導入設備讓其信任，使用工具抓包，能夠清晰看見HTTPS數據包的信息。同樣是qq郵箱登錄的數據，區別就在于使用工具之前我讓設備信任了自己的CA證書。當然這里并沒有抓到明文密碼，這是由于qq郵箱還有其他數據安全加密設置，參考下圖：

總結：HTTPS證書信任機制出現問題，還是可以進行中間人攻擊截取用戶明文的數據流量。

（2）HTTPS為什么存在安全風險？

從上一節可以了解到，HTTPS加密協議也是存在中間人攻擊的，為了解攻擊的原理，我們可以先來看一看HTTPS的握手過程。這里以支付寶為例，利用WireShark獲取支付寶的HTTPS數據流量進行分析

客戶端發送Client Hello請求建立HTTPS鏈接，服務器返回Server Hello回應客戶端接收到請求，并下發HTTPS證書給客戶進行驗證，客戶端驗證通過，發送對稱加密密鑰，進行數據交換。能夠非常直觀的看出握手流程，簡單的HTTPS實現圖

如果客戶端未嚴格校驗證書或者忽略了域名校驗，攻擊者可以通過對客戶端進行操作，從而繞過客戶端的弱校驗，達到欺騙服務器，進行中間人攻擊的目的。簡單例舉了HTTPS存在的問題

• 忽略SSL證書校驗

• 忽略域名校驗

• 證書信息泄漏?

情況一、信任任何證書。出現這種情況的原因很有可能是使用的開源通信庫存在缺陷，還有就是開發人員在開發過程中未連接生產環境的服務器，為解決認證過程中證書報錯的問題只能暫時修改代碼使其APP信任任意證書，而在上線前未對此代碼進行處理。通過對APP進行逆向分析，可以在客戶端代碼中發現存在開發人員忽略證書認證的代碼片段

該段代碼重寫了谷歌原有X509Certificate[]的校驗方式，進行了覆蓋，卻沒有添加自己的證書校驗代碼，導致證書校驗的代碼為空，攻擊者可以使用任意證書進行流量劫持，這里利用了工具自簽名一個證書，即可進行HTTPS證書校驗繞過，參考下圖：

情況二、信任證書管理機構（CA）頒發的證書。這種情況的APP可以信任任何CA頒發的證書，據說這類的證書只需50美元就能買到。此類問題出在AFNetworking 2.5.2及之前的版本，也就是說如果某APP使用了此版本的開源通信庫，在不安全Wifi網絡中的黑客、VPN網絡中的職工或者國家支持的黑客，只要使用CA頒發的證書就可以對該APP的HTTPS加密數據進行監聽或者篡改，在源代碼中發現配置代碼片段：

該段代碼一個重要的配置ALLOW_ALL_HOSTNAME_VERIFIER,使其信任官方的CA證書，無論是頒發給誰的，只要是官方的證書，都可以信任，從而導致驗證失敗。

情況三、信任合法證書。這種情況的APP只信任對自己而言合法的證書，首先我們看一下SSL認證的原理的前三步：1、客戶端向服務器傳送客戶端SSL協議的版本號，加密算法的種類，產生的隨機數，以及其他服務器和客戶端之間通訊所需要的各種信息。2、服務器向客戶端傳送SSL協議的版本號，加密算法的種類，隨機數以及其他相關信息，同時服務器還將向客戶端傳送自己的證書。3、客戶端利用服務端傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過期，發行服務器證書的CA是否可靠，發行者證書的公鑰能否正確解開服務器證書的“發行者的數字簽名”，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續進行下一步。那么如何讓APP信任非法的證書呢，看上文說到的3步，我們只需要做到在合法性驗證的時候能夠欺騙APP，通訊就不會中斷。在手機本地添加一個信任證書，APP在本地驗證的時候，由于手機信任該證書，APP默認也信任該證書，達到欺騙APP的目的。

情況四、這種情況是采用了服務器和客戶端雙向認證的措施，即客戶端在確認服務器是否合法之后，服務器也要確認客戶端是否是合法的（服務器要求客戶發送客戶自己的證書。收到后，服務器驗證客戶的證書，如果沒有通過驗證，拒絕連接；如果通過驗證，服務器獲得用戶的公鑰）。正是這個原因，我們在測試APP時會發現盡管我們信任了burp或者fiddler的證書，可是在進行登錄操作時APP依然會顯示網絡連接錯誤，此時服務端已經知道客戶端可能是非法的，然后拒絕連接。如果你是開發人員，想分析HTTPS流量也很簡單：使用burp導入客戶端證書，此時burp就可以與服務器正常的建立連接，你也可以正常的截取到數據包了，只要獲取到證書以及密鑰，即可進行數據獲取。APP開發時，在本地實現證書導入，應用于HTTPS雙向校驗傳輸證書的密鑰可以在本地獲取，參考實現代碼片段

分析上例代碼可以發現，應用于證書client.p12的密鑰，猜測在he.b()/he.a()函數中會進行一個處理，利用hook技術，對函數內容進行hook，即可獲取字符串信息，該信息包括了密鑰和其他的數據，利用獲取的密鑰和本地保存的client.p12證書，即可模擬開發人員進行HTTPS雙向驗證，截取用戶明文信息。

兩者代碼片段分別如下

總結：HTTPS安全協議不安全，主要還是在設計階段選擇了單向校驗，在加上后期沒有進行嚴格的證書校驗，導致HTTPS證書驗證被繞過，其次就是采用了雙向校驗，但是本地校驗的代碼沒有進行安全保護，攻擊者通過動態HOOK，也是可以獲取CA證書以及其密鑰信息。

（3）HTTPS中間人攻擊的危害？

HTTPS雖然也存在中間人攻擊，但是和ARP局域網攻擊又存在很大的差別，參考下圖：

ARP欺騙，數據信息攻擊獲取范圍是介于路由器和用戶手機之間，也就是OSI模型的數據鏈路層，路由器和用戶手機之間傳輸的信息都可能被攻擊者截取，通過中間人攻擊獲取在同一局域網下所有用戶的數據流量

SSL欺騙，SSL是位于OSI模型的傳輸層和應用層之間，可以通過繞過APP本地校驗機制實現在傳輸層和應用層之間的數據傳輸（數據到達應用層，也就是給用戶的展示界面是明文的）截取，從而獲取明文數據，或者是HTTPS相關的密鑰信息。僅存在用戶自己手機內部，只能獲取攻擊者本身操作的賬戶流量信息

總結：就攻擊范圍來講，在客戶端的攻擊HTTPS攻擊是影響面比較窄，但就針對服務端的攻擊影響來看，兩者是一致的，都可以操作服務端數據，獲取服務端信息，都能危及服務器安全。

幾維安全解決方案

應對傳輸協議缺陷，流量被劫持的安全風險，幾維安全建議以協議安全，數據安全，應用代碼安全為目標來應對中間人攻擊。

首先對客戶端APP的可執行文件DEX、SO、Mach-O被破解的風險，幾維安全采用源代碼保護技術，對DEX文件進行JAVA2C，將JAVA代碼下沉至Native層，并在該層對轉化后的偽C代碼進行強度最高的虛擬化處理，對SO和Mach-O文件采用源代碼編譯的方式，直接把C/C++/Object-C/Swift工程項目編譯成KiwiVM虛擬化后的結果，保障客戶的不被攻擊者逆向破解。

其次對在終端設備運行的客戶端運行時會在內存中傳遞重要的數據，通過接入幾維安全防御安全SDK，可以對手機環境，進程防護，代碼注入等方面進行全面的檢測和防護，保證本地內存數據不遭受惡意篡改。

同時，針對通道存在的明文傳輸和協議破解偽造風險，幾維安全提供結合代碼虛擬化技術和白盒技術研發的白盒密鑰SDK。利用SDK對傳輸的數據和存儲的數據進行高強度的加密，且提供動態加密、數據完整性校驗等功能，支持多種對稱加密、非對稱加密和哈希算法，嚴格保障了數據的完整性和保密性。

?

轉載于:https://www.cnblogs.com/ydaq/p/11120308.html

總結

以上是生活随笔為你收集整理的传输协议不安全，数据泄露谁之过？——流量劫持技术分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。