擡頭看天 | 談談移動端抓包方式和原理及如何防犯中間人攻擊

抓包對每個開發者來講，應該說是最基本的技能之一，最近因公司需求接觸了一些抓包相關，也遇到了一些奇怪的問題，因而作一個簡單的記錄,但願對你們有所幫助哈。

移動端經常使用抓包工具

工欲善其事，必先利其器 ,要抓包，怎麼可能沒有好的工具，對於普通抓包來講，咱們有下面幾個工具

Fiddler

在 windows 環境很是好，提供了一系列抓包方式及後續的腳本，劃重點，腳本，這也是衆多人喜歡的緣由。

注意：在mac支持不好，新版軟件缺乏核心功能腳本，體驗不好。

Charles

體驗nice,在Mac，windows體驗都可以，支持定時存儲，不支持相關腳本。(這也是爲何不如fiddler火的緣由，在mac體驗很好)

AnyProxy

阿里的抓包工具，在網頁上使用，使用簡單，支持js腳本。批量抓包能夠考慮使用。

總結

如下經驗皆爲我的使用體驗。

若是是 windows用戶，只是想隨便抓抓練手，fiddler 不佳之選，mac用戶 選擇 Charles。

若是想抓完以後順便分析分析數據，寫入數據庫，那麼 AnyProxy 和 fiddler 能夠知足需求，mac用戶直接考慮 AnyProxy便可，不要問爲何，問就是 fiddler 在mac就是一坨稀飯。

相關的使用教程，一抓一大把，我這裏就不敘述了。

舒適提示：記得安裝證書，記得Android7.0如下(以上使用xp框架，或者別的方式)

經常使用抓包工具原理

好像有點跑題了，接下來回到正軌，上面這些抓包軟件原理是什麼呢？

中間人攻擊

什麼是中間人攻擊？

一圖勝千言(小灰的圖)

簡而言之，小紅和小綠兩人要通訊，結果被中間人小黑偷聽並分別轉發了。

不是有https嗎？

不少人認爲，用https不就好了嗎，我有證書作校驗啊，但普通的https依然至關於裸奔，相似的 上面的工具經過代理加僞造根證書依然能夠抓取https，具體原理看下面分析。

原理分析

咱們以 charles舉例。charles至關於一箇中間人代理。當客戶端與服務器通訊時， charles 接收服務器的證書，而後動態生成一張證書發送給客戶端，而後 charles 做爲中間代理在客戶端 和 服務器 之間通訊，因此相關通訊的數據 能夠被 Charles 攔截。

以下圖描述：

具體步驟以下：

1. 客戶端 向服務器 發起 HTTPS 請求
2. Charles 攔截客戶端請求，假裝成客戶端向服務器進行請求
3. 服務器 向 客戶端 返回服務器的 CA證書。 (實際上已經被 Charles 攔截)
4. Charles 攔截服務器的響應，獲取服務器證書公鑰，而後本身製做一張證書，替代服務器的證書後發給 客戶端。
5. 客戶端 接收到 服務器(其實是Charles的證書) 的證書後，生成一個對稱祕鑰，並用 Charles 發送回來的證書公鑰加密，發送給 服務器(實際發送給了 Charles)
6. Charles 攔截客戶端的響應，用本身的私鑰解密對稱祕鑰 (這裏已經拿到了對稱祕鑰)，而後用服務器證書公鑰加密，發送給服務器。
7. 服務器用本身的私鑰解密對稱祕鑰，向客戶端(實際是 Charles)發送 響應
8. Charles 攔截服務器響應，替換成本身的證書會後發送給客戶端。
9. 至此，連接創建， Charles 拿到了 服務器證書的公鑰 和 客戶端和服務器協商的對稱祕鑰，以後就能夠解密或者修改加密的報文了。

這也就是爲何抓https 須要安裝相應的證書，由於咱們得讓客戶端認爲證書有效，即咱們的證書也是根證書，不過Android7.0之後，用戶手動安裝的證書都不會被信任，因此通常咱們藉助xp框架或者別的方式

如何防範中間人攻擊？

判斷是否設置代理

網絡請求時，判斷客戶端當前是否設置代理，若是設置代理，就禁止其訪問。

客戶端本地證書效驗

客戶端本地作證書校驗,而且設置不只僅校驗公鑰,設置完整的正式校驗模式。這樣的話,證書會校驗請求的時候不只僅校驗域名,會將證書中的公鑰及其餘信息也進行校驗,這樣的話,中間人僞造的證書就沒法經過驗證,沒法進行抓包。

Https請求和相應的數據進行加密

對證書加密的數據再次進行加密，這樣即便對方已經將證書替換，那麼看到的數據仍舊是一堆亂碼後的數據。

最後，以上皆爲本人真實理解和實際感覺，抓包有風險，你們練練手便可，切勿黑灰產業哈

參考博客

• Charles抓取https數據的原理，如何防止中間人攻擊

我是 Petterp ,若是你以爲個人文章對你有所幫助，歡迎點贊👏 ，若是有任何想法和問題，隨時歡迎評論區一塊兒討論。👨‍💻‍