點擊右上角【關注】發哥微課堂頭條號，get更多相關技能~
引子：
上週拿到一個線上複測的項目，中間有一個明文傳輸問題，這個問題平時基本不記，客戶那測試基本都是內網環境，上線基本都是 https。這個問題之前是這樣測試的：抓包，如果內容是明文就記這個問題，這裡存在很多的問題。
問題 1：線上環境 https 為什麼抓到的包是明文
這個問題很容易搜到答案，原因在於 https 的加密是傳輸的過程，burp 攔截的數據包沒有走到傳輸那一步，它只相當於攔截的瀏覽器的數據，相當於就是客戶端。
https 抓包原理第一步，抓包程序將服務器返回的證書攔截，第二步，給客戶端返回一個自己的證書，第三步，客戶端發送的數據包程序用自己的證書解密，第四步，再用攔截的證書加密發送給服務器。
這就是為什麼 burp 需要抓 https 的網站時，需要給瀏覽器導入自己證書的原因。這樣，很自然的就會想到第二個問題。
問題 2：那明文傳輸問題應該怎麼測
內網的測試環境基本不會 https，線上環境基本都是 https，如果有複測線上環境的情況，最簡單的就是直接看 url 地址了，最明顯不過。如果是 APP，沒有 url 地址，那就直接抓包，可以使用 wireshark 抓包查看，如果嫌麻煩，直接到 burp 的 HTTP history 中查看 url 是否有 https 即可。
之前有一個誤區，認為 burp 抓到的 https 包是亂碼的，認為那就是 https 加密的結果。首先 https 加密後的內容，是在 burp forward 之後的，其次如果是 https 加密，消息頭的內容也都是密文。如果之前有這樣的誤區，那麼就會有第三個問題。
問題 3：burp 攔截的一堆亂碼是什麼
類似於上圖，這個是因為編碼的問題，其實它和圖片上傳攔截的數據包很像，那些亂碼屬於 application/octet-stream 類型，準確點應該是頭部會有一個 Content-Type 字段值為 application/octet-stream。這個類型通常指二進制流，或者其他的一些文件內容，這些內容通常需要一些客戶端打開，所以感覺 burp 還原幾率很小。
圖片中是有這個字段的，很多包是類似於這種亂碼，但沒有這個字段，是因為對於 tomcat 中間件，如果有未知類型的內容進行傳輸，則會默認使用 application/octet-stream 這種方式，這時候 burp 攔的就是那種亂碼形式。
問題 4：關於修復問題
最終的修復方法還是使用 https。
之前看到的修復建議有寫在前端使用 js 對敏感數據進行加密這種修復方式，嚴格來說，作用不是很大。假設有一個惡意攻擊者發起了一個釣魚 wifi，你連上了這個 wifi，去登錄一個程序，這個程序對賬號和密碼進行了 js 加密，那麼通過中間人攔截數據包後就不會顯示明文，但作用並不大，其實還是相當於明文傳輸，把這個數據包發送服務器是沒問題的，所以說作用並不大。
有人提出過類似的思路，js 加密敏感字段，後端接收值後在通過 md5 + 鹽的方式進行數據庫存儲，那麼對於後端來說接收的不管是明文還是進過 js 加密的密文，都是一樣的，作用在於中間人攔包後獲取不到明文，數據庫被拖後很難還原密碼這些。其實兩端加密相當於沒有加密。
但不能說前端 js 加密就沒有用處，作用上一段說了，會起到一定的意義，例如支付寶不僅使用了 https，也使用了前端 js 加密，如下圖：
所以，關於修復方法，必須使用 https，其次能結合前端 js 對敏感信息進行加密更好，如果業務要求高，像銀行那樣，可以同時使用客戶端控件進行多重加密。
閱讀更多 發哥微課堂 的文章
