IPFS能否阻止Bybit黑客攻击？
Bybit最近遭遇的黑客攻击（打开新窗口）导致14亿美元损失，这起事件提醒我们前端验证的重要性，特别是在Web3生态系统中的dapp前端。根据我们撰写本文时掌握的信息，IPFS通过本地验证本可以在这起复杂攻击中作为预防性防线，甚至可能完全阻止攻击。本文将回顾此次攻击的已知细节，分享我们对IPFS作用的观点，并深入介绍我们在Interplanetary Shipyard（打开新窗口）为推动生态系统健康发展所主导的技术工作。如果您是dapp开发者，可以直接跳过最后部分，我们在那里提供了具体建议和相关工具链接。
攻击是如何发生的？
简而言之，黑客成功入侵了托管Safe前端（通过app.safe.global提供服务）的AWS S3存储桶，并在攻击发生前几天上传了恶意版本的前端。该前端专门针对Bybit冷钱包，导致多签钱包所有者在签署恶意交易时，前端界面隐藏了交易的恶意性质。
目前尚不清楚黑客具体如何获得AWS S3存储桶的访问权限。一些报告表明，可能是某位开发者的凭证通过社会工程学手段被泄露。来源
安全是分层的
软件系统安全采用分层方法，通常称为"深度防御"（打开新窗口）。这种策略涉及实施多重安全措施，而非依赖单一保护机制。如果某一层失效，其他层可提供备用保护。现代网络是一个复杂的生态系统，随着涉及资金规模的增加，对更好安全措施的需求也在增长。
在这起攻击事件中，我们识别出三个导致攻击成功的失效点：
- Safe前端未经验证（信任基于DNS、TLS PKI和HTTP服务器返回有效数据的信念）
- Safe多签所有者签署了恶意交易
- Safe智能合约中没有额外的审批层来阻止恶意交易执行
由于IPFS主要关注第一点（通过内容寻址（打开新窗口）验证数据的能力），我们将重点讨论这方面。其他两点涉及更广泛的生态系统需求，如明确签名（而非智能合约钱包中常见的盲签名）、增强安全性而非削弱安全性的改进用户体验，以及更有效的交易验证工具。以太坊社区迅速响应，解决了第二点，发布了多个（打开新窗口）工具（打开新窗口）和文档（打开新窗口），帮助用户在签署前验证交易。
IPFS与前端验证
IPFS项目长期倡导更广泛地采用客户端验证。一年多前，我们发布了一篇博客文章（打开新窗口），讨论了客户端验证的重要性以及IPFS如何提供帮助。
端到端完整性：只要您的Dapp用户拥有您分享的CID，他们就可以通过本地验证确保运行的是您发布的完全相同的代码。本地验证至关重要，因为Dapp与区块链交互，恶意代码可能导致用户资金损失。完整性与免信任相邻——因为验证消除了对数据来源信任的需求。
摘自《IPFS上Dapp的现状：信任与验证（2024）》（打开新窗口）
对于DWeb、Web3和IPFS生态系统中的许多人来说，通过密码学哈希验证实现的端到端完整性并不陌生。事实上，在攻击发生后不久，Gnosis创始人分享了名为Eternal Safe（打开新窗口）的Safe前端开源分叉的CID，而Safe团队则对其服务和前端进行取证审查，这让我们感到某种程度的证实：来源
网络上的原生内容寻址
IPFS项目最长期的目标之一是将客户端验证集成到浏览器中，使CID成为一等公民。在理想情况下，您应该能够在浏览器中使用ipfs://协议使用CID，而不必在计算机上安装作为独立进程运行的"完整"IPFS节点。
为此，我们启动了多个项目，取得了不同程度的成功。我们反复遇到的主要挑战是浏览器限制和缺乏可扩展性API，这些API本应允许将信任从提供内容的具体来源转移到自认证标识符（如CID），使得无论来源如何都能在本地验证内容。
与HTTP服务器相比，通过扩展商店分发的浏览器扩展更难被攻破，因为推出是分阶段而非即时进行的，且经过审查的代码资产可以捆绑在扩展本身内。此外，发布要求作者签名，确保用户从可信来源安装扩展。我们正在研究如何将Service Worker IPFS网关打包为浏览器扩展（打开新窗口）以改善用户体验。
基于CID的自认证方法与同源策略（打开新窗口）存在张力：同源策略是网络的基本安全机制，通过DNS和PKI将信任锚定到来源。然而，鉴于子资源完整性(SRI)（打开新窗口）允许对子资源进行哈希验证，我们希望能与标准机构和浏览器供应商合作，在此基础上扩展并提供验证顶级资源（如HTML、JS、CSS等）的机制。
话虽如此，在我们推进使CID成为浏览器一等公民的努力的同时，我们为dapp开发者提供了一些当前即可实施的具体建议。
面向dapp开发者的IPFS
作为dapp开发者，您今天需要了解并将三个关键事项融入开发工作流：
- 如何将前端部署到IPFS
- 如何安全地向用户传递发布CID
- 用户如何安全地检索前端并确信它与您发布的是同一个
让我们快速了解这些方面的最新技术现状。
将前端部署到IPFS
为使IPFS部署尽可能无缝，我们最近发布了ipfs-deploy-action（打开新窗口），这是一个GitHub Action，可轻松将您的前端（或任何其他静态资产）作为CI/CD流水线的一部分部署到IPFS。它封装了我们多年来建立的最佳实践，如使用CAR文件（打开新窗口）进行本地CID生成和固定。
该Action使用开放工具构建，对构建过程不做假设，因此可与任何静态站点生成器配合使用。此外，它使用CID设置提交状态，从而提高了部署的可见性和可审计性。
向用户传递CID
将前端部署到IPFS后，您需要向用户传递CID。这可以通过几种方式完成：
- 在GitHub发布说明中发布CID，如Eternal Safe（打开新窗口）和Uniswap（打开新窗口）所做的那样
- 通过ENS（打开新窗口）或IPCM（打开新窗口）在链上发布CID
- 定期发布加密签名的IPNS（打开新窗口）记录
- 利用具有强化解析器（仅DNSSEC（打开新窗口）和/或非ICANN解析器，如ENS（打开新窗口）的这个）的DNSLink（打开新窗口）
这些方法各有不同的安全属性和权衡，其中一些已在IPFS上的Dapps（打开新窗口）博客文章中进行了评估。最快上手运行的方法是使用GitHub，它提供了强大的安全性和可审计性。至少，重用GitHub Releases来发布原始源代码和CID。这为您的用户提供了一种以可验证方式加载前端的方法。
检索前端
有了CID后，用户有几种方式检索前端：
- 本地IPFS节点（如IPFS Desktop（打开新窗口））与IPFS Companion浏览器扩展（打开新窗口）结合提供ipfs://cid URI支持，具有最高级别的安全性，包括本地CID验证和缓存。这是桌面的优秀解决方案，但在移动设备上不起作用。
- 使用Service Worker Gateway（打开新窗口）进行浏览器内验证正在改善，然而，worker的初始引导仍与HTTP服务器绑定，如果HTTP服务器被成功利用，可能提供恶意的客户端代码。我们目前正在研究如何将Service Worker IPFS网关打包为浏览器扩展以弥补这一差距并改善用户体验。
- 公共福利HTTP网关（如ipfs.io、dweb.link和eth.limo）返回反序列化的资产，最终用户无法验证。正如IPFS原则（打开新窗口）文档所述，验证很重要，如果您不验证，那就不是IPFS。这相当于供应链中的"不是您的密钥，不是您的奶酪"。
合作提案：让我们携手合作
Interplanetary Shipyard（打开新窗口）是一个独立集体，维护IPFS和libp2p生态系统中许多最流行的实现。如果您希望提高dapp的安全性，我们很乐意听取您的意见，请联系contact[at]ipshipyard.com。
有兴趣为您的dapp探索通过Service Worker Gateway和安全列表发布CID来强制执行前端安全的浏览器扩展吗？想要赞助浏览器改进以消除对DNS和PKI作为信任锚的依赖吗？让我们聊聊（打开新窗口）！
结语
在安全性和可用性之间找到适当平衡是困难的。如果本文有一个要点，那就是在用户与区块链交互的多个步骤中，验证都很重要。IPFS不是银弹，但如果Bybit Safe多签钱包的所有者从本地IPFS节点加载前端，这次攻击很有可能得以避免。