BurpSuite 代理原理和證書釘扎檢測技術

BurpSuite是一個手動Web安全測試工具，工具可以攔截HTTP、HTTPS、WebSockets這三種協議的網絡流量，通過便捷UI圖形化界面呈現給安全測試者，測試者只需分析流量中所呈現出的安全問題。

下面主要討論HTTP、HTTPS的流量轉發過程，以及如何防范中間代理人篡改證書抓包HTTPS流量問題。

HTTP協議抓包

這個協議的流程是最簡單的。

deepseek_mermaid_20250909_22424a

瀏覽器根據代理設置，將原本要發往 example.com:80 的 HTTP 請求包，發送給了本地的 127.0.0.1:8080 (Burp)。
Burp 接收到請求，這是其可以攔截和查看明文數據的關鍵。
Burp 以自己的網絡身份（源IP變為Burp主機的IP，即 192.168.1.100）將請求原樣或修改后轉發給真正的目標服務器 93.184.216.34:80。
目標服務器處理請求，并將響應發送回請求的源地址，即 192.168.1.100（Burp所在機器）。
操作系統將收到的響應數據包交給監聽端口的 Burp。
Burp 將響應返回給瀏覽器。

HTTPS協議抓包

這個協議的流程稍微復雜些。需要理解 Burp Suite 是如何作為中間人介入這個過程的。其核心在于，Burp 需要讓瀏覽器信任Burp“偽造”的證書。

如下主要介紹，服務器證書和Burp證書分別做了什么操作。

先復習一下無代理的HTTPS流程：
下面的流程主要是瀏通信雙方共同計算出一個相同的會話秘鑰，用于對稱加密。

sequenceDiagram participant C as 瀏覽器 participant S as 服務器 Note over C, S: TLS 握手開始 C->>S: 1. Client Hello （支持加密套件、隨機數C） S->>C: 2. Server Hello （選擇加密套件、隨機數S） + Server Certificate （服務器證書） Note right of C: 瀏覽器驗證證書： 1. 頒發者CA是否可信？ 2. 域名是否匹配？ 3. 是否在有效期內？ C->>S: 3. Pre-Master Secret （用證書公鑰加密） Note over C, S: 雙方根據隨機數C、S、Pre-Master 計算出相同的會話密鑰 S->>C: 4. Finished （用會話密鑰加密） C->>S: 5. Finished （用會話密鑰加密） Note over C, S: 安全通道建立完成！ C->>S: 應用數據傳輸 （全部用會話密鑰加密）

對上圖關鍵步驟的說明：

Server Certificate (服務器證書)：

它是什么？一個數字文件，由公共可信的證書頒發機構 (CA)簽發。
它的作用？做身份認證：向瀏覽器證明“我就是 example.com”，而不是一個釣魚網站。
攜帶公鑰：證書內包含了用于加密的公鑰。瀏覽器會用這個公鑰來加密信息，只有持有對應私鑰的真正服務器才能解密。
瀏覽器如何驗證它？瀏覽器和操作系統中都預裝了一個可信CA根證書列表。瀏覽器會檢查收到的服務器證書是否由這個列表中的某個CA簽發。如果是，則證書可信；如果不是，瀏覽器就會彈出嚴重警告。（需要先理解證書信任鏈流程。）

Pre-Master Secret ：

由瀏覽器生成一個隨機值（Pre-Master Secret），用服務器證書里的公鑰加密后，發送給服務器。
只有擁有對應私鑰的服務器才能解密它。隨后，雙方利用這個值和之前交換的隨機數，各自生成完全相同的會話密鑰。

會話密鑰 (Session Keys) ：

生成會話秘鑰后，所有的應用數據（HTTP請求/響應）都將使用這個對稱的會話密鑰進行加密和解密。
對稱加密比非對稱加密（公鑰私鑰）快得多，適合大量數據傳輸。

有代理的HTTPS流程：

deepseek_mermaid_20250909_4025e2

對上圖及證書角色的詳細解釋：

本地證書（Burp Suite 的 CA 根證書）：

Burp的證書需要你手動安裝到瀏覽器或操作系統中的證書。它由 Burp Suite 自己生成，代表 Burp 自己成為一個私有的、本地的證書頒發機構 (CA)。
它的作用？建立信任錨點。你告訴瀏覽器：“這是我的測試工具，我完全信任它頒發的任何證書，請不要報警”。一旦安裝并信任此證書，瀏覽器就會將 Burp CA 加入到它的“可信CA根證書列表”中。（需要先理解證書信任鏈流程。）

從服務器下載的證書（在 Burp 場景中）：

當 Burp 收到瀏覽器對 https://example.com 的請求時，它會立即同時進行兩個獨立的 TLS 握手。
Burp ? 服務器：Burp 作為一個標準的客戶端，與真實服務器完成 TLS 握手。它會收到并驗證服務器的真實證書（步驟3）。如果服務器的證書無效（如域名不匹配、由不可信CA簽發），Burp 會在 Alerts 標簽頁向你告警。
瀏覽器 ? Burp：與此同時，Burp 會動態地、實時地為 example.com 這個域名偽造一個證書。這個假證書的“頒發者”是 Burp CA（步驟4）。

瀏覽器驗證的是誰的證書？

瀏覽器收到的是 Burp 代理發送給瀏覽器“偽造”的證書（步驟4）。偽造證書的大致流程： Burp拿到真實證書后，截取出證書里的關鍵字段，Burp用它自己的CA私鑰，完全“重新簽發”了一張新的假證書。這個新證書里的公鑰，是 Burp 自己臨時生成的密鑰對中的公鑰，而不是服務器的公鑰。
瀏覽器執行驗證流程：“這個證書是給 example.com 的嗎？是的。是可信CA簽發的嗎？我來看看頒發者...哦，頒發者是 ‘PortSwigger CA’（Burp CA），而我已經把這位CA加入信任列表了。所以這個證書沒問題！” → 驗證通過。
因為瀏覽器信任了 Burp CA，所以它信任 Burp CA 頒發的所有證書。

解密的奧秘：

瀏覽器用 Burp 假證書里的公鑰加密 Pre-Master Secret（步驟5）。
因為 Burp 偽造了這個證書，所以它持有對應的私鑰，因此它可以解密這個 Pre-Master Secret。
至此，Burp 就成功截獲了這個最關鍵的參數。然后，它再拿著這個參數，用服務器真實證書的公鑰加密，發送給服務器（步驟6）。
最終，Burp 和瀏覽器之間建立了一條加密通道（使用會話密鑰①），而 Burp 和服務器之間建立了另一條獨立的加密通道（使用會話密鑰②）。Burp 坐在中間，可以解密兩條通道上的所有流量。

注：企業的網絡架構中也會有很多HTTPS流量轉發場景，原理是一樣的。把企業中的流量代理服務器替換成BurpSuite去代入理解即可。

WebSockets協議了解

WebSockets協議是什么？
WEB領域里已經有一個主流通信協議——HTTP了（HTTPS只是加密后的HTTP），為什么還要有WebSockets協議？
因為 HTTP 協議有一個缺陷：通信只能由客戶端發起。

WebSockets解決一件HTTP不能完成的事：
WebSockets協議解決了服務器可以主動向客戶端推送信息，客戶端也可以主動向服務器發送信息，是真正的雙向平等對話。（這個技術也屬于服務器推送技術的一種）

標識符：
協議標識符是ws（如果加密，則為wss），服務器網址就是 URL。
ws://example.com:80/some/path
wss://example.com:80/some/path

協議的數據格式和HTTP類似，但又有所區別，用到在查吧，這里只做一個大致了解即可。

證書釘扎是一種防止攻擊者自己簽發的證書進行中間人攻擊的一種安全機制，用于預防CA遭受入侵或其他會造成CA簽發未授權證書的情況。

采用公鑰固定時，網站/應用會提供已授權公鑰的哈希列表，指示客戶端在后續通訊中只接受列表上的公鑰。

證書釘扎（Certificate Pinning）

證書釘扎也稱HTTP公鑰固定（或稱 HTTP公鑰釘扎，HTTP Public Key Pinning，縮寫HPKP）

核心：應用程序或服務器不再信任所有根CA，而是預先知道并“鎖定”它期望看到的特定證書（或公鑰）。

簡單來說：服務器使用了白名單校驗制度。

這個技術可以有效防止客戶端使用中間代理的情況，一般應用在APP領域。

公鑰固定原理：

flowchart TD A[App啟動或首次請求] --> B[從服務器獲取當前證書鏈] B --> C[提取當前證書公鑰 （或整個證書）] C --> D[計算其哈希值 （如SHA256）] D --> E{與App內預嵌的 可信哈希值比對} E -- 匹配 --> F[校驗成功 連接繼續] E -- 不匹配 --> G[校驗失敗] subgraph G [失敗處理措施] H[立即終止連接] I[記錄安全事件] J[向服務器告警] K[通知用戶] end

對上圖流程的詳細說明：

預置信任錨點（核心原則：將信任錨點提前并固化）：
- 在開發階段，開發人員提取目標服務器證書的公鑰（或整個證書）。
- 計算該公鑰的哈希值（例如 SHA-256）。
- 將這個哈希值硬編碼到應用程序的源代碼中，或者放在一個配置文件中，然后隨應用一起發布。
運行時校驗：
- 當應用程序（或啟用了釘扎的瀏覽器）與服務器建立 HTTPS 連接時，它會照常接收服務器的證書鏈。
- 在完成了標準的證書驗證（檢查域名、有效期、CA簽名等）之后，釘扎邏輯會額外執行以下操作：
  - 從服務器發送來的證書中提取出公鑰。
  - 使用相同的哈希算法（如 SHA-256）計算該公鑰的哈希值。
  - 將計算得到的哈希值與應用程序內部預置的哈希值進行比對。
決策與執行：
- 匹配：如果兩個哈希值完全一致，說明服務器提供的證書正是應用程序所信任的特定證書。連接被允許建立，數據傳輸繼續。
- 不匹配：如果哈希值不一致，即使該證書由全球可信的CA（如 Let's Encrypt, DigiCert）簽發且完全有效，應用程序也會立即終止連接。這就是它防御中間人攻擊的關鍵——Burp Suite 生成的假證書，其公鑰哈希值絕對不可能與App內預置的真證書公鑰哈希值相同。

APP公鑰固定防御過程：

你試圖用 Burp Suite 攔截一個啟用了證書釘扎的 App 的流量。
App 發起 HTTPS 請求，請求被路由到 Burp。
Burp 與真實服務器建立連接，獲取到服務器的真實證書。
Burp 動態生成一個偽造的證書，這個證書的域名雖然正確，但是由 Burp 自己的 CA 簽發的，因此其公鑰與真實證書的公鑰完全不同。
Burp 將這個偽造的證書返回給 App。
App 的釘扎邏輯啟動：
- 提取偽造證書的公鑰。
- 計算其哈希值。
- 與內部預置的正確公鑰哈希值進行比對。
- 結果：不匹配！
App 立即觸發錯誤，斷開連接。你在 Burp Suite 中通常會看到 SSL Handshake Failed、Connection Reset 之類的錯誤，根本無法看到任何明文流量。

證書釘扎的優缺點：

優點	缺點
極大的增強安全性：有效防止`MITM攻擊`，即使攻擊者控制了CA或用戶信任了惡意根證書也無濟于事。	維護復雜性：服務器證書到期或更換時（尤其是更換CA），必須同時更新客戶端App內預置的釘扎信息，否則會導致大規模連接中斷。
減少信任依賴：不依賴外部CA系統的絕對安全。	部署風險：如果部署不當（例如只釘扎了一個證書而沒有備份），證書失效會導致服務徹底癱瘓。
針對性強：只保護特定的、重要的域名和連接。	安全性并非絕對：如果App本身被逆向分析，攻擊者可以提取出預置的哈希值，從而偽造證書（但需要一定逆向、脫殼技術，難度相對高）。

為了平衡安全性和維護性，通常采用以下策略：

備份 pin：不僅釘扎當前證書的公鑰，還釘扎備份證書的公鑰，以防當前證書出現意外。
有效期：為釘扎信息設置有效期，超過期限后不再檢查，以避免長期失效的風險。
報告機制：校驗失敗時，不僅斷開連接，還嘗試向服務器發送報告，幫助管理員發現問題。

注：在制定安全方案時，需要考慮的事項。

posted on 2025-09-09 11:11 Mysticbinary 閱讀(202) 評論(0) 收藏舉報

刷新頁面返回頂部