那個釣魚頁面就是真正的頁面

你收到一則訊息，講的是一份共享文件、一筆被標記的登入、或一張發票。你點下去。一個 Microsoft 登入頁打開了，而且是真的那一個：對的字型、對的 Logo、在欄位之間切換時的那個小動畫、那道貨真價實、會讓你手機震動的多因素提示。你核准了。你進去了。一切都不覺得有哪裡不對，因為幾乎沒有任何東西真的不對。你輸入的那個頁面，就是 Microsoft 的登入頁。只是和它對話的人，不是你。

六月下旬，Netcraft 的 Harry Everett 記錄下 一套名為 Bluekit 的釣魚工具組做出了這一跳，BleepingComputer 也在同一週 做了報導。 Bluekit 以服務的形式販售：一套代管的釣魚工具組，附帶 Outlook、Gmail、iCloud、GitHub 以及一兩款加密貨幣錢包的範本，還內建一個替你撰寫誘餌郵件的助手。它的新把戲頂著一個自 2022 年一位代號 mr.d0x 的研究者描述以來就一直繞著轉的名字：中間人瀏覽器（browser-in-the-middle）。

真正的頁面，串流給你。

老派釣魚搭的是一個贗品。有人把登入頁複製下來，架在一個看起來很像的網域上，然後賭你不會去看網址列。防禦就是圍繞著這一點長大的：辨出假貨、抓住 URL 裡的錯字。

接著出現的是像 Evilginx 這樣的反向代理工具組。它不複製頁面。它坐在連線的中間，是一個「中間人對手」（adversary in the middle），把你的流量轉送到真正的網站，並在流量經過時順手刮走工作階段 cookie。（那個 cookie 是網站在你登入後交給你瀏覽器的小型權杖，這樣它就不會在你每點一下時都重問一次密碼。）偷走它就能打敗大多數多因素登入，因為攻擊者拿走的是一次已完成登入的證明，而不是密碼本身。

中間人瀏覽器更怪一些，而某種意義上也更簡單。攻擊者在自己的伺服器上跑一個真正的瀏覽器，把它指向那個如假包換的登入頁。一個名為 rrweb、原本是為了重播使用者工作階段而打造的開源函式庫，把那個活生生的頁面序列化，再透過 WebSocket——一條你的瀏覽器與他們的瀏覽器之間持久的雙向通道——把它串流給你。你的瀏覽器把那個真頁面的結構渲染出來，彷彿是你自己載入的一樣。你看的不是螢幕截圖，也不是影片。你是在遠端遙控一個坐在真店裡的瀏覽器，而你的按鍵、你的滑鼠、你的多因素核准，全都中繼回去給它。當登入完成時，它是在他們的瀏覽器裡完成的，由他們的伺服器鑄造出工作階段權杖。從第一秒起，他們就擁有了你的工作階段。

何苦費這番工夫？因為它說服你的方式是贗品永遠做不到的。沒有一個假頁面會搞砸。而且因為攻擊者用同一個一致的瀏覽器去和真網站對話，這次登入不會觸動指紋不符的警報（你的裝置與代理之間那些細微的不一致），而這些警報有時正是反向代理工具組露餡的地方。Netcraft 在單單一週內就數出了大約七十個全新的 Bluekit 主機名。那是一件產品的產出量。

擋不住它的東西。

先從壞消息講起，因為壞消息很多。

多因素驗證，以它常見的那些形式，擋不住這個。一組一次性驗證碼和一道推送核准證明的是同一件事——某次登入正在此刻發生——而這次攻擊正需要這場登入發生，因為登入的人正是攻擊者。證明的人是你，留下工作階段的人是他們。

較新的工作階段強化機制，幫得上的忙比你期望的還少。Netcraft 指出，裝置綁定工作階段憑證（Device Bound Session Credentials），一種把工作階段 cookie 綁在它被簽發那台裝置上的機制，「無法防範中間人瀏覽器，但確實能對中間人對手提供一些防護」。這個工作階段一開始就誕生在攻擊者的裝置上，所以把它綁到那台裝置上，保護的是攻擊者，不是你。任何在登入之後才加裝上去的東西都來得太晚，因為到那時候，攻擊者已經正當地握有了工作階段。

隔離也擋不住它，這一點值得明明白白地說。一個把每個分頁都跑在用完即丟虛擬機裡的瀏覽器——就像我們的——能夠圍堵一個頁面對你的電腦能做的事。中間人瀏覽器對你的電腦什麼都不做。它只借用你的雙手做一次登入，然後把成果留在一台你永遠不會看到的伺服器上。你大可以在關掉分頁的那一刻就把自己這邊的工作階段丟掉。真正要緊的那份副本，從來就不在你這邊，丟不丟由不得你。用完即丟能防禦一長串攻擊，而中間人瀏覽器不在那張清單上。

擋得住它的東西。

更厲害的假頁面偵測器在這裡幫不上忙，因為根本沒有假頁面。解法是一份攻擊者抄不下來的憑證。

密碼和一次性驗證碼共享一個致命的性質：它們都是字串。你把一個字串輸進一個串流過來的頁面，線路把它載走，另一端的瀏覽器把它重放。這就是整套商業模式。

通行密鑰是一把私鑰，住在你的裝置上，永遠不離開它。登入意味著你的 Mac 在你用 Touch ID 核准之後，去簽署一道一次性挑戰，而它交回來的那個簽章，綁定在你當初為它建立通行密鑰的那個確切網站上。由此衍生出兩個後果，兩個都打破了中間人瀏覽器。

第一，沒有東西可以打字，所以也沒有東西可以中繼。這份秘密從不出現在頁面裡、從不跨越 WebSocket、也從不待在某個表單欄位裡等著 rrweb 把它串流回去。攻擊者的瀏覽器想問多少次都行；簽署這件事發生在你 Mac 裡的一顆晶片上，那是攻擊者的伺服器搆不到的地方。

第二，你那真銀行的通行密鑰，是註冊在你真銀行的網域上的。當攻擊者的主機把頁面端到你面前時，你的 Mac 去找一把在那裡根本不存在的通行密鑰，於是什麼都不提供。本來一按就成的登入，沒有發生。那道沉默——那個從不觸發的自動填入、那把不在清單上的通行密鑰——正是那個假網址列以前會給你、如今再也給不了的警告。

出借你 Mac 憑證的兩種方式。

瀏覽器的設計在這裡很重要，因為通行密鑰只有在它抵達你登入的那個地方時，才保護得了你。

Bromure 把每一個瀏覽工作階段都跑在你 Mac 上一台用完即丟的 Linux 虛擬機裡，一台獨立的小電腦，當你關掉視窗時它就把它抹除。那能很好地圍堵惡意頁面，但也帶出一個明顯的問題：如果瀏覽器住在一台用完即丟的機器裡，那你儲存的那些登入是從哪裡來的？Bromure 讓你逐設定檔去選，並刻意把這個選擇拆成兩個開關。

把它們拆開正是重點。把你整個鑰匙圈分享進一個工作階段，是那個便利的預設值；只分享通行密鑰，才是對本文這次攻擊免疫的那個選項。只給通行密鑰有它自己的開關，所以那個抗釣魚的選擇只花你撥一下開關，而不是一整個安全專案。你可以跑一個只有唯一一種驗證方式的設定檔，而那種方式無法從你的螢幕上被串流帶走。

這解決不了什麼。

一個開關不是力場，而它的界限很要緊。

最大的那個值得再說一次。如果你透過一個中間人瀏覽器頁面用密碼登入，就算後面跟著一次性驗證碼或一道推送，攻擊者也拿到了一個可用的工作階段，而用完即丟 VM 或聰明瀏覽器的任何特性都奪不回來。只給通行密鑰的分享，保護的是你用通行密鑰的那些登入，其他的一概不保護。還有很多網站不提供通行密鑰，對於那些網站，老建議是唯一的建議：不要去點訊息裡的登入連結，自己打開那個網站。

偵測幫得上忙，而 Bromure 也用它：過濾式 DNS 會封鎖已知的惡意網域，還有一個 AI 釣魚檢查會在你動作之前替一個頁面的 URL 與表單結構評分。兩者都縮小了機率。兩者都不是保證，而中間人瀏覽器正是被設計來讓偵測更難。一週七十個全新主機名跑贏了大多數封鎖清單，而一個內容掃描器找不到假頁面可標記。偵測抓得到粗心的攻擊者，抗釣魚的憑證抓得到謹慎的那一個。

還有最稀鬆平常的那個界限：人是可以被說服去做很多事的。如果一則有說服力的訊息把你帶到一個沒有通行密鑰的網站，而你打進一個你在別處重複用過的密碼，那麼從頭到尾都沒有任何瀏覽器設定參與其中。只給通行密鑰的分享不會讓你刀槍不入。但對於那些最要緊的登入——你的信箱、你的程式碼代管處、你的身分提供者——它移除了攻擊者上門要找的那個字串，留下一把他們搆不到的鑰匙。

那個假網址列就要退休了。

我們重複了二十年的建議（檢查 URL、找掛鎖圖示、懷疑頁面）都假設攻擊者必須偽造某樣東西。中間人瀏覽器什麼都不偽造。它把如假包換的真品交到你手上，並提著敞開的袋子站在後面。

老實的結論是：一個安全優先的瀏覽器不會讓你對這個免疫，而比起假裝，我們寧可把這話說出來。答案從你的眼睛移到了你的憑證。面對一個你無法和真貨區分的頁面，能撐得住的防線是用一樣你抄不下來的東西登入：一把通行密鑰，在你的 Mac 上簽署、綁定到真網域、從不向攻擊者的網域提供。Bromure 的角色又小又具體。它讓那件事成為輕鬆的預設值——靠著允許一個設定檔只分享通行密鑰、別的都不分享。安裝它，為那些你輸不起的帳戶打開只給通行密鑰，然後讓下一個看起來完美無瑕的登入頁，向你要一份你再也不必交出去的秘密。