昨天我們探討了 HTTP 的狀態碼，並提到早期的 HTTP 協定是採「純文字明碼」傳輸的。

今天，我們就要來實戰演練：如果一個網站沒有實作 HTTPS 加密，而且開發者還便宜行事地把登入資訊塞在網址（也就是 GET 請求）裡面，這對網管或駭客來說，簡直就像是在馬路上裸奔一樣危險！

我們將扮演攔截者的角色，使用 Wireshark 的殺手級功能，直接看光這些機密資訊。

一、製造帶有帳密的 HTTP GET 請求

我們將使用開發者常用的測試 API 網站 httpbin.org，來模擬一次夾帶帳號密碼的網頁請求。

【實作練習】

1. 開啟 Wireshark 擷取，並套用 http 顯示過濾器。
2. 打開終端機，刻意在網址後面加上 username 與 password 參數發出請求：

   curl "http://httpbin.org/get?username=admin&password=MySecretPassword"
   

畫面解析：
從終端機的回應可以看到，伺服器成功收到了我們的參數。同時，背後的 Wireshark 也立刻抓到了一個又長又惹眼的 GET 封包。

二、在封包細節中看穿明碼參數

封包抓到了，我們來看看它在底層長什麼樣子。

【實作練習】
停止抓包後，點選剛剛那行 GET 封包，並在中間的詳細資訊窗格層層展開：Hypertext Transfer Protocol -> Request URI -> Request URI Query。

畫面解析：
你看！Wireshark 非常貼心地幫我們把網址後面的參數拆解開來。
username=admin 與 password=MySecretPassword 就這樣毫無保留地以純文字（明碼）顯示在我們眼前。同時，你也可以看見下方最原始的 16 進位與 ASCII 碼對照區塊，密碼字串就大剌剌地寫在那裡。這就是為什麼現代網站絕對禁止使用 HTTP 傳輸敏感資料的原因！

三、殺手級功能：追蹤 TCP 串流 (Follow TCP Stream)

在真實世界中，封包數量成千上萬，甚至一個網頁的回應會被切成好幾十個封包來傳送。如果我們要在封包列表裡一個一個找、一段一段拼湊，那絕對會看到眼睛脫窗。

這時，我們就要派出 Wireshark 最強大的分析工具：「追蹤 TCP 串流」。

【實作練習】
對著剛剛那個 GET 封包按 「右鍵」，選擇 「Follow (追蹤)」 -> 「TCP Stream (TCP 串流)」。

畫面解析：
點擊後，Wireshark 會彈出一個全新的視窗。這就是這場通訊的「完整對話紀錄」！

• 紅色字體：代表客戶端（也就是我們的 Ubuntu 終端機）送給伺服器的所有內容。你可以清楚看到我們的 HTTP 請求標頭，以及那串致命的明碼網址。
• 藍色字體：代表伺服器（httpbin.org）回傳給我們的所有內容。包含 200 OK 狀態碼，以及完整的 JSON 回應資料。

透過這個功能，無論資料被切成多少個封包，Wireshark 都能幫我們完美還原還原雙方的對話原貌。

🎯 今日小結

今天我們透過實戰，親眼見證了 HTTP 明碼傳輸的危險性。如果你在公共咖啡廳使用未加密的 Wi-Fi 連上這種網站，任何一個開著 Wireshark 並且處於「混雜模式」的有心人士，都能輕鬆用「Follow TCP Stream」撈出你的帳號密碼。

🔜 明日預告

剛剛我們是把密碼放在網址裡 (GET)，那如果是正規的表單登入，把密碼藏在封包的「身體」裡 (POST)，是不是就比較安全了呢？
明天 [Day 17]，我們將繼續破解迷思，實戰擷取 HTTP POST 請求封包，看看藏在 Body 裡的秘密是否能逃過 Wireshark 的法眼！我們明天見。