Common Security Issues in Crypto Wallets

加密錢包正成為絕大多數用戶進入 Web3 世界的第一道門，但這個「門」本身卻存在大量源自架構設計與環境誤解的安全缺陷。來自 Hex 的安全研究員 Andy 在這場演講中，系統性地拆解了瀏覽器擴充套件錢包與行動端錢包的攻擊面，並以具體漏洞案例說明問題的根因與防禦方向。

錢包面臨的威脅可分為三類：惡意網頁或開發者透過 post message 傳遞偽造請求；具備設備實體存取權的攻擊者可轉儲記憶體、暴力破解 KDF 派生密碼或篡改 OS 安全儲存；以及利用 UI 資訊不完整來欺騙用戶做出錯誤決策。擴充套件錢包的架構是：網頁透過 Provider 發出請求，Content Script 作為中間傳遞層，Background Script 負責實際的授權與敏感操作決策。行動端則透過 URI scheme 與 Intent filter 接收外部請求，攻擊面不同，但「嚴格驗證輸入」的核心要求一致。

第一個大類漏洞是訊息驗證不足。錢包內部的多個 UI 步驟（例如「切換網路確認」→「代幣轉帳確認」）依靠 post message 串接，Background Script 必須清楚區分訊息來自 Content Script 還是內部 UI 元件。若驗證不足，攻擊者可以構造精心設計的訊息，跳過「顯示授權介面」這一步，直接觸發「執行簽名」的 handler，使錢包誤以為用戶已審核並批准交易。第二個問題是來源驗證：postMessage 訊息體中的 `origin` 欄位可被頁面內的 iframe 任意設定（例如偽稱自己是 `build.devxy`），若錢包以此欄位來顯示「請求站點」，UI 就會呈現假的合法域名。正確做法是使用瀏覽器提供的只讀 `MessageEvent.origin`，並對照白名單，拒絕來自 iframe 或不可信上下文的訊息。此外，即使 origin 驗證正確，攻擊者仍可利用同形字符（homograph attack）或不可見填充字符讓惡意域名在視覺上與受信任域名完全相同，防禦方式是對域名字串進行規範化（normalize）並在 UI 中完整顯示不截斷。

網路新增流程也存在根本性缺陷。部分錢包在用戶添加自定義網路時，會從 RPC 端點動態取回 chain ID 並與用戶輸入比對，但若 RPC 端點由攻擊者控制，兩個值皆為惡意值，比對永遠通過。同時，重複性檢查若只比對名稱與 URL 而非 chain ID，攻擊者仍可注入重複 chain ID 的惡意網路，讓錢包顯示假餘額、假交易記錄，並在廣播前對用戶交易進行前置或後置操作。最後一個問題出在 Token UI：許多錢包的 ERC20 代幣轉帳介面未顯示 `value` 欄位。惡意代幣合約可將 `transfer()` 設計為 `payable`，網站在誘導用戶簽署看似無害的「1 USDT 轉帳」時，附加大額 ETH 作為 msg.value，合約執行後鎖定這部分資產，用戶毫不知情。Andy 的團隊因此建立了 Token Risk API，在多條鏈上分析代幣行為並於錢包 UI 層顯示風險標示，讓錢包從「簽名工具」升級為「風險感知介面」。