你是否能通过 Rekt 测试？

对于区块链开发者来说，最大的挑战之一是客观地评估他们的安全态势并衡量其进展。为了解决这个问题，由 Trail of Bits 的首席执行官 Dan Guido 领导的一个 Web3 安全专家工作组在今年早些时候会面，创建了一个简单的测试来分析区块链团队的安全性。我们称之为 Rekt 测试。

Rekt 测试是模仿 The Joel Test。 由软件开发者 Joel Spolsky 在 25 年前开发的 The Joel Test 用 12 个简单的“是”或“否”问题，取代了用于确定软件团队成熟度和质量的拜占庭式流程。区块链行业需要类似的东西，因为今天复杂的指导方针与其说是告知，不如说是令人沮丧。

Rekt 测试侧重于最简单、最普遍适用的安全控制，以帮助团队评估安全态势并衡量进展。一个组织对这些问题的回答“是”的次数越多，他们就越能信任其运营的质量。这不是区块链安全团队的最终检查清单，但这是一种开始对重要安全控制进行知情讨论的方式。

在今年早些时候的 Gathering of Minds 会议上，一组行业领导者被要求解决区块链生态系统中缺乏网络安全标准的问题。其中一个讨论由 Trail of Bits 的首席执行官 Dan Guido 领导。其他参与者包括 Nathan McCauley(Anchorage Digital)、Lee Mount (Euler Labs)、Shahar Madar (Fireblocks)、Mitchell Amador (Immunefi)、Nick Shalek (Ribbit Capital) 等。通过他们的讨论，创建了 Rekt 测试：

Rekt 测试

1. 你是否记录了所有的行动者、角色和权限？
2. 你是否保留了你所依赖的所有外部服务、合约和预言机的文档？
3. 你是否有一个书面且经过测试的事件响应计划？
4. 你是否记录了攻击你系统的最佳方法？
5. 你是否对所有员工进行身份验证和背景调查？
6. 你的团队中是否有一名成员的角色定义中包含安全？
7. 你是否要求生产系统使用硬件安全密钥？
8. 你的密钥管理系统是否需要多人和物理步骤？
9. 你是否为你的系统定义了关键不变量，并在每次提交时对其进行测试？
10. 你是否使用最好的自动化工具来发现你代码中的安全问题？
11. 你是否接受外部审计并维护漏洞披露或 漏洞赏金 计划？
12. 你是否考虑并减轻了滥用你系统用户的途径？

区块链技术的格局是多样化的，超越了区块链，包括去中心化协议、钱包、托管系统等，每种技术都有独特的安全细微之处。以下对 Rekt 测试问题的解释反映了该小组一致同意的最佳实践，绝不是详尽无遗或绝对的。Rekt 测试的目的不是建立严格的基准，而是激发区块链社区中关于安全的有意义的对话。因此，请将此解释视为此关键对话中的垫脚石。

1. 你是否记录了所有的行动者、角色和权限？

全面记录影响区块链产品的所有行动者、角色和权限至关重要，因为这可以明确谁可以访问系统资源以及他们被授权执行哪些操作。行动者指的是与系统交互的实体；角色是分配给行动者或群体的预定义权限集；权限定义了特定的权利和许可。

全面记录这些实体有助于进行全面测试，使开发人员（和外部审计师）能够识别安全漏洞、不正确的访问控制、去中心化程度以及特定妥协场景中的潜在风险暴露。解决这些问题可以增强系统的整体安全性和完整性。该文档还可用作审计师比较实际访问权限与记录的访问权限的参考点，识别任何差异，并调查潜在的安全风险。

2. 你是否保留了你所依赖的所有外部服务、合约和预言机的文档？

与外部智能合约、预言机和桥的交互是区块链应用程序的许多关键功能的基础。新的区块链应用程序或服务也可能依赖于组织外部开发的金融Token的假定安全态势，这增加了其复杂性和攻击面。因此，即使是将最佳安全程序集成到软件开发过程中的组织也可能成为破坏性安全事件的受害者。

记录区块链系统使用的所有外部服务（如云托管服务和钱包提供商）、合约（如 DeFi 协议）和预言机（如定价信息）至关重要，以便识别风险暴露并减轻事件影响。这样做将帮助你回答以下基本问题：

• 我们如何知道外部依赖项何时遭受安全事件？
• 我们在什么具体条件下宣布发生安全事件？
• 当我们检测到安全事件时，我们将采取哪些步骤？

回答这些问题将帮助你在不可避免地发生安全事件影响你无法控制的依赖项时做好准备。你应该能够注意到依赖项的输出、界面或假定的程序状态的任何变化（无论是否无害）；评估其对安全的影响；并采取必要的后续步骤。这将限制对你系统的安全影响，并有助于确保其不间断运行。

3. 你是否有一个书面且经过测试的事件响应计划？

虽然区块链领域的安全性不同于传统产品安全性（在传统产品安全性中，更集中或封闭的系统可能更容易控制），但两者都需要有效的事件响应计划，以帮助在面对安全事件时保持弹性。该计划应包括通过自动化和手动程序来识别、遏制和补救事件的步骤。组织应提供培训，以确保所有团队成员都熟悉该计划，并且该计划应包括通过内部 和 外部渠道进行事件通信的步骤。应定期测试此计划，以确保其是最新的和有效的，尤其是在区块链安全世界变化如此之快的情况下。你应该创建自己的事件响应 (IR) 计划，并且可以使用此 Trail of Bits 指南作为资源。

对于区块链系统，尤其重要的是，IR 计划应通过确保组织不过分依赖任何个人来减轻关键人物风险。该计划应预测关键人员可能无法使用或受到胁迫的情况，并概述确保运营连续性的步骤。开发人员应考虑去中心化访问控制、实施基于仲裁的批准以及记录程序，以便多个团队成员做好响应准备。

对于区块链系统，尤其重要的是，事件响应应具有前瞻性，而不仅仅是被动反应。应该在创建 IR 计划的同时设计合约，使用诸如受保护的启动之类的策略来逐步部署新代码。开发人员应考虑他们的合约中是否需要可暂停功能，以及协议的哪些部分应该或不应该可升级或去中心化，因为这将影响团队在事件期间的能力。

4. 你是否记录了攻击你系统的最佳方法？

通过构建一个威胁模型，记录所有可能攻击系统的途径，你可以了解你现有的安全控制是否足以减轻攻击。威胁模型应以可视方式展示产品的整个生态系统，包括来自软件开发之外的信息，例如应用程序、系统、网络、分布式系统、硬件和业务流程。它应该识别系统的所有弱点，并清楚地解释攻击者如何利用它们，并结合来自相关现实世界攻击的信息，以帮助你避免犯同样的错误。

此信息将帮助你了解你是否将精力集中在正确的位置——即，你当前减轻攻击的努力是否与攻击最可能发生的方式和位置相一致。它将帮助你了解对你系统的成功攻击会是什么样子，以及你是否已充分准备好检测、响应和遏制它。一个好的威胁模型应该消除意外，并使你的团队能够有意识地计划缓解措施。

5. 你是否对所有员工进行身份验证和背景调查？

假名开发在区块链行业中很常见，但它阻碍了责任承担、合同执行以及在区块链产品中及其利益相关者之间建立信任。恶意行为者可以利用缺乏身份验证和背景调查来干扰产品的开发、窃取资金或造成其他严重损害，并且机构将没有或只有有限的手段来惩罚他们。近年来，朝鲜黑客使用虚假 Linkedin 帐户申请真实职位，并冒充公司提供欺诈性职位。这些做法直接导致了严重的黑客攻击，包括 Axie Infinity 的 5.4 亿美元损失。

因此，公司必须知道所有员工的身份并对其进行背景调查，包括那些使用公共假名的人。公司还必须在其访问控制和监控方面达到更高的成熟度；例如，他们应该根据员工的角色、背景及其居住地（即，考虑当地法律和管辖权）做出有关运营安全的谨慎决定。

6. 你的团队中是否有一名成员的角色定义中包含安全？

团队中需要有一个人负责确保区块链系统的安全。针对区块链技术的威胁正在迅速发展，即使是单一的安全事件也可能是毁灭性的。只有专门的安全工程师才有必要的时间、知识和技能来识别威胁、分类事件和修复漏洞，这有助于在你开发产品时建立对其的信任。

理想情况下，这个人将创建并监督一个专门的团队，并将安全放在其工作职责的最前沿，最终负责推动组织回答此列表中的其他问题“是”。他们将监督跨部门的工作，与开发人员、管理员、项目负责人、管理人员和其他人员合作，以确保安全实践包含在组织的各个方面。

7. 你是否要求生产系统使用硬件安全密钥？

凭据填充、SIM 卡交换攻击和鱼叉式网络钓鱼几乎使密码和短信/推送双因素身份验证的保护能力失效。对于有高风险和价值的组织来说，防网络钓鱼硬件密钥是唯一合理的选择。应使用特殊的硬件密钥来访问公司的资源，包括电子邮件、聊天、服务器和软件开发平台。应特别注意保护生产中任何非常难以或不可能逆转的操作。

在你的组织内部使用这些密钥是称职的链下基础设施管理的重要指标。如果这看起来像是你的 IT 团队的一项繁重的工作，请不要灰心。2016 年，Google 发布了一项研究，表明实施这些密钥很简单，在其 50,000 名员工中很受欢迎，并且可以有效防御恶意攻击。U2F 硬件Token，例如 YubiKey 和 Google Titan，是硬件密钥的不错选择。

8. 你的密钥管理系统是否需要多人和物理步骤？

如果单个人员维护控制你系统的密钥，他们可以单方面进行更改，从而产生巨大的影响，而无需相关利益相关者的共识。如果攻击者破坏了他们的凭据，他们可以完全控制核心资产。

相反，应该设置密钥管理，以便重要决策需要多人和物理访问的共识或仲裁。多人完整性是一种有效的安全策略，用于国防和传统金融等高风险行业；它们可以同时防止通过攻击者、内部威胁（例如，流氓员工）和胁迫进行的破坏。在为基于仲裁的设置选择受信任的个人集合时，至关重要的是选择那些值得信赖且有适当激励的人，因为包括不合适或不一致的个人可能会破坏系统对胁迫的抵抗力。通过额外要求物理密钥管理（例如，使用物理保险箱或air-gapped设备存储密钥），你将大大降低任何个人或任何个人的密钥或密钥片段被破坏时发生的欺诈、盗窃、滥用或错误的风险。

区块链组织应使用多重签名或多方计算 (MPC) 控制和冷存储解决方案，至少用于持有其大部分资产的中央钱包，或者选择使用符合条件的托管人，具体取决于具体法规和需求。解锁多重签名钱包的密钥应存储在受信任的硬件上，例如硬件安全模块 (HSM)、安全 enclave 或防篡改硬件钱包。

必须仔细部署和配置受信任的硬件，以限制其攻击面。例如，不应提取机密，并且应避免网络连接。组织还应建立一个严格的程序来根据阈值、受影响的钱包、目的地和发起交易的关键人员等参数来转移资金。

9. 你是否为你的系统定义了关键不变量，并在每次提交时对其进行测试？

不变量是在程序执行过程中必须保持为真的条件。不变量可以针对整个系统（例如，没有用户的Token数量应超过总供应量）或针对特定函数（例如，计算价格函数不能导致免费资产）。理解和定义不变量有助于开发人员明确系统期望的行为，并帮助安全工程师评估这些行为是否符合预期。这为安全测试提供了一个路线图，并降低了意外结果和失败的可能性。

定义不变量首先要用简单的英语记录对系统所做的假设。这些不变量应涵盖广泛的功能和密码属性及其有效状态、状态转换和高级行为。指定良好的系统可能具有数百个属性：你应该首先关注最重要的属性，并不断努力提高其覆盖深度。为确保代码遵循不变量，必须在整个开发过程中使用自动化工具（例如模糊器或基于形式方法的工具）对其进行测试。

10. 你是否使用最好的自动化工具来发现你代码中的安全问题？

自动化安全工具是成功安全策略的基线要求。完全自动化的工具（例如静态分析器）会自动查找常见错误并且需要低维护，而半自动化的工具（例如模糊器）使开发人员可以更进一步并检查逻辑问题。许多此类工具可用，但我们建议使用那些由顶级安全工程师积极使用的工具，这些工具已发现错误并拥有久经考验的记录。

Trail of Bits 的智能合约安全工具使用最先进的技术，可以集成到你的 CI 系统和编辑/测试/调试周期中。它们包括 Echidna，一种用于 Solidity 智能合约的智能合约模糊器，以及 Slither，一种用于 Solidity 智能合约的静态分析器。在开发和测试期间自动使用这些工具可帮助开发人员在部署之前捕获关键安全漏洞。

11. 你是否接受外部审计并维护漏洞披露或 漏洞赏金 计划？

为了识别区块链代码中的漏洞，仅仅依靠内部安全团队是不够的。相反，组织必须与拥有现代区块链技术深入知识的外部审计师合作，涵盖低级实施、金融产品及其基本假设，以及为现代应用程序提供支持的库、服务、桥和其他基础设施。（跟踪区块链安全事件的网站上充斥着一些公司，它们有时没有为复杂的变更寻求外部指导。）

安全审计师帮助识别漏洞，并为重组你的开发和测试工作流程提供建议，以便这些漏洞不再出现。在寻找审计时，重要的是要明确哪些组件正在接受审查，哪些组件被排除在外，以及应该应用的工作量级别，包括通过使用工具。通过了解审计的益处和局限性，组织可以专注于审计结束后改进所需的其他领域。

此外，漏洞 披露 或 漏洞赏金 计划可以通过为用户或研究人员提供公开访问的选项来增强你的安全态势，如果他们发现错误，可以联系你。通过建立这些计划，组织表明愿意与独立的 漏洞猎人 合作——如果没有他们，他们可能会在社交媒体上公开披露这些错误，甚至为了自己的利益而利用它们。虽然这些计划有很多好处，但重要的是要考虑它们的局限性和陷阱。例如，漏洞赏金猎人 不会提供有关提高系统安全成熟度或减少长期错误可能性的建议。此外，你的团队仍将负责分类 漏洞 提交，这可能需要持续的专用资源。

12. 你是否考虑并减轻了滥用你系统用户的途径？

许多针对区块链的攻击，例如网络钓鱼、Twitter/Discord 诈骗和“杀猪盘”，试图欺骗 用户 在使用你的产品时采取不可弥补的行动。即使一个组织拥有最专业设计的安全系统来保护 自己，其自己的用户仍然可能容易受到攻击。例如，区块链应用程序通常依赖于加密签名，这增加了网络钓鱼尝试的可能性。开发人员应考虑使签名易于识别（例如，使用 EIP-712），并且应创建并推广其用户的指南，以最大限度地降低被滥用的风险。

为了避免此类攻击，组织的安全策略应包括 滥用性 测试，你的团队会在其中考虑攻击者如何造成社会、心理和身体上的伤害。了解重大财务或社会危害的风险将有助于你的团队评估必要的流程和缓解措施。例如，如果你的协议的用户包括高影响力的利益相关者（例如退休基金），则基于协议费用的创建保证基金可能有助于在发生妥协时使用户整体完整。

别被 rekt

这 12 项控制措施并不是可以确定你的安全态势的唯一措施，但我们相信，即使区块链技术正在迅速创新，它们也将增强每位开发人员的软件和运营安全性。此测试不应作为一次性练习；这些问题具有持久的价值，并且应该为组织提供路线图，因为他们在继续发展和开发新产品。回答“是”并不意味着你将完全避免安全事件，但它可以授权你和你的团队避开行业中最糟糕的标签：被 rekt。

• 原文链接： blog.trailofbits.com/202...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～