將您的錢包連接到新的、未經驗證的 dApp 有哪些風險？

錢包連接到未經驗證的 dApp 的風險

1. 當用戶將錢包連接到未經驗證的去中心化應用程序時，他們通常會在不完全了解範圍的情況下授予廣泛的權限。許多 dApp 要求無限的代幣批准，使合約能夠在未經進一步同意的情況下重複提取資產。

2. 惡意合約可能嵌入在連接時觸發自動轉賬的邏輯，特別是當錢包持有帶有轉賬掛鉤或重入漏洞的代幣時。這導致了許多事件，用戶在批准交易後幾秒鐘內就失去了全部餘額。

3. 虛假接口模仿合法協議，誘騙用戶簽署偽裝成標準連接請求的網絡釣魚負載。這些有效負載可能包含惡意簽名請求，這些簽名請求以“錢包連接”或“登錄”為幌子，授權任意合約​​調用。

4. 一些 dApp 部署在具有最少節點基礎設施的不起眼的 EVM 兼容鏈上，增加了搶先交易、三明治攻擊甚至鏈重組的可能性，從而使預期的狀態轉換失效，從而使用戶面臨無聲的資金損失。

5. MetaMask 等錢包擴展在提示簽名請求之前不會驗證合約字節碼完整性。 dApp 前端中的單個受損依賴項（例如被劫持的 CDN 託管庫）可以將惡意簽名邏輯直接注入用戶的瀏覽器上下文中。

令牌批准利用模式

1. 舊版 ERC-20 批准在協議升級和鏈遷移過程中仍然有效。攻擊者通過在新部署的共享相同功能選擇器的惡意合約上重複使用舊的批准來利用這一點。

2. 授予代理合約的批准特別危險，因為底層實現可以在不通知用戶的情況下升級。控制管理密鑰的攻擊者可以隨時交換邏輯以耗盡批准的代幣。

3. 一些 dApp 使用基於許可的鏈下批准，要求用戶簽署 EIP-712 消息。如果域分隔符配置錯誤或消息結構不明確，簽名可以在網絡上重放或重新用於未經授權的傳輸。

4. 錢包很少在批准提示期間顯示完整的 ABI 編碼的通話數據。用戶無法驗證批准的目標是真實的令牌地址還是攻擊者使用類似的校驗和大小寫或 Unicode 同形異義詞技巧部署的相似地址。

前端供應鏈漏洞

1. 當開發人員錯誤地在全局範圍內公開敏感引用時，已觀察到通過 npm 依賴項注入的第三方分析腳本會從內存錢包對像中竊取私鑰。

2. dApp 構建者使用的受損 UI 框架有時會包含隱藏的事件偵聽器，這些事件偵聽器會捕獲助記詞輸入字段中的擊鍵，即使這些字段已通過 CSS 禁用或隱藏。

3. 瀏覽器擴展衝突會產生競爭條件，錢包提供商無法正確攔截簽名請求，從而導致使用不正確的參數或隨機數簽名的原始交易廣播。

4. 未縮小的 JavaScript 捆綁包通常包含硬編碼的 API 密鑰、錢包地址或測試網憑證，攻擊者會抓取並重新利用這些憑證來模擬受信任的後端服務，同時通過惡意中繼器路由流量。

網絡級欺騙策略

1. 惡意 RPC 端點提供偽造的區塊鏈狀態，顯示虛假的代幣餘額或捏造的交易確認，以在啟動不可逆轉的操作之前誘導虛假的信心。

2. DNS 中毒攻擊將嘗試訪問官方 dApp 域的用戶重定向到託管相同 UI 但指向攻擊者控制的智能合約的鏡像站點。

3. 中間人代理攔截錢包和 dApp 之間的 WebSocket 連接，改變響應負載以隱藏待批准的內容或抑制由已知詐騙合約地址觸發的警告橫幅。

4. 與 dApp 入門流程捆綁在一起的測試網水龍頭有時會與合法合約一起部署惡意合約，鼓勵用戶與兩者進行交互——在主網上引入利用邏輯之前建立信任。

常見問題解答

問：dApp 可以僅通過連接我的錢包而不簽署任何交易來竊取資金嗎？答：是的。僅連接不會轉移資金，但許多 dApp 會立即請求代幣批准或調用使用用戶錢包上下文執行任意代碼的委託調用模式。

問：使用硬件錢包可以消除這些風險嗎？答：不會。硬件錢包可以保護私鑰，但仍然簽署前端請求的交易。如果 dApp 顯示誤導性信息或構造欺騙性通話數據，硬件設備將按照指示對其進行簽名。

問：連接開源 dApp 是否自動安全？答：不一定。公共源代碼不保證部署完整性。攻擊者經常部署經過審核的合約的修改版本，其中包含細微的更改（例如更改的所有者地址或後門回退功能），從而繞過靜態分析工具。

問：為什麼有些錢包擴展程序顯示警告，而其他錢包擴展程序則不顯示？答：警告行為取決於擴展提供商維護的實時合約地址信譽數據庫。這些數據庫落後於新的部署，並且通常缺乏對鮮為人知的鍊或新簽訂的合約的覆蓋。