你能通过Rekt测试吗？- Trail of Bits博客
区块链开发者面临的最大挑战之一是客观评估自身安全态势并衡量其进展。为解决这一问题，由Trail of Bits CEO Dan Guido领导的Web3安全专家工作组今年早些期制定了一套简单的测试标准，用于分析区块链团队的安全状况。我们称之为Rekt测试。
Rekt测试模仿了25年前由软件开发人员Joel Spolsky创建的Joel测试，用12个简单的"是/否"问题取代了判断软件团队成熟度和质量的复杂流程。区块链行业需要类似标准，因为当今复杂的指导文件往往令人困惑而非提供有效信息。
Rekt测试专注于最简单、最普遍适用的安全控制措施，帮助团队评估安全态势和衡量进展。组织对这些问题的肯定回答越多，就越能信任其运营质量。这不是区块链安全团队的终极清单，而是开启关于重要安全控制措施知情讨论的起点。
在今年初的"思想汇聚"会议上，行业领袖们应对区块链生态系统中网络安全标准缺失的挑战。其中一场讨论由Trail of Bits CEO Dan Guido主持，其他参与者包括Nathan McCauley（Anchorage Digital）、Lee Mount（Euler Labs）、Shahar Madar（Fireblocks）、Mitchell Amador（Immunefi）、Nick Shalek（Ribbit Capital）等。通过讨论，Rekt测试应运而生：
Rekt测试问题
- 是否记录了所有参与者、角色和权限？
- 是否记录了所有依赖的外部服务、合约和预言机？
- 是否有书面化且经过测试的事件响应计划？
- 是否记录了攻击系统的最佳方法？
- 是否对所有员工进行身份验证和背景调查？
- 团队中是否有明确负责安全的成员？
- 生产系统是否要求使用硬件安全密钥？
- 密钥管理系统是否需要多人和物理步骤？
- 是否为系统定义关键不变量并在每次提交时测试？
- 是否使用最佳自动化工具发现代码中的安全问题？
- 是否进行外部审计并维护漏洞披露或漏洞赏金计划？
- 是否考虑并减轻滥用系统用户的途径？
区块链技术领域多样化，不仅包括区块链，还包括去中心化协议、钱包、托管系统等，每个都有独特的安全细微差别。Rekt测试问题的后续解释反映了该小组达成共识的最佳实践，绝非详尽或绝对。Rekt测试的目的不是建立刚性基准，而是激发区块链社区关于安全的有意义对话。因此，请将此解释视为这一关键对话的垫脚石。
1. 是否记录了所有参与者、角色和权限？
全面记录所有影响区块链产品的参与者、角色和权限至关重要，因为这明确了谁可以访问系统资源以及他们被授权执行哪些操作。参与者指与系统交互的实体；角色是分配给参与者或组的预定义权限集；权限定义特定权利和许可。
这些实体的彻底文档化有助于全面测试，使开发人员（和外部审计员）能够识别安全漏洞、不当访问控制、去中心化程度以及特定入侵场景中的潜在暴露。解决这些问题增强了系统的整体安全性和完整性。文档还作为审计员的参考点，以比较实际访问权限与文档记录，识别任何差异，并调查潜在安全风险。
2. 是否记录了所有依赖的外部服务、合约和预言机？
与外部智能合约、预言机和桥的交互是区块链应用许多关键功能的基础。新的区块链应用或服务可能还依赖于组织外部开发的金融代币的假定安全态势，这增加了其复杂性和攻击面。因此，即使将最佳安全程序集成到软件开发过程中的组织也可能成为破坏性安全事件的受害者。
记录区块链系统使用的所有外部服务（如云托管服务和钱包提供商）、合约（如DeFi协议）和预言机（如定价信息）至关重要，以便识别风险暴露和减轻事件影响。这样做将帮助您回答以下基本问题：
- 我们如何知道外部依赖项遭受安全事件？
- 我们宣布安全事件的具体条件是什么？
- 检测到事件时我们将采取哪些步骤？
回答这些问题将帮助您在不可避免的安全事件影响您控制之外的依赖项时做好准备。您应该能够注意到依赖项输出、接口或假定程序状态的任何变化（无论是否无害）；评估其安全影响；并采取必要的后续步骤。这将限制对您系统的安全影响，并帮助确保其不间断运行。
3. 是否有书面化且经过测试的事件响应计划？
虽然区块链领域的安全与传统产品安全不同（更集中或封闭的系统可能更容易控制），但两者都需要有效的事件响应计划，以帮助在安全事件面前保持韧性。该计划应包括通过自动和手动程序识别、遏制和修复事件的步骤。组织应提供培训，确保所有团队成员熟悉该计划，并应包括通过内部和带外渠道沟通事件的步骤。该计划应定期测试，以确保其最新和有效，特别是考虑到区块链安全世界变化的速度。您应创建自己的事件响应（IR）计划，并可以使用此Trail of Bits指南作为资源。
对于区块链系统，IR计划通过确保组织不过度依赖任何单个人来减轻关键人员风险尤为重要。该计划应预测关键人员可能不可用或受胁迫的场景，并概述确保运营连续性的步骤。开发人员应考虑分散访问控制、实施基于法定人数的批准并记录程序，以便多个团队成员准备好响应。
对于区块链系统，事件响应应主动而非仅被动尤为重要。合约应在创建IR计划时使用如防护启动等策略逐步部署新代码来设计。开发人员应考虑是否希望在合约中包含可暂停功能，以及协议的哪些部分应或不应可升级或去中心化，因为这将影响团队在事件期间的能力。
4. 是否记录了攻击系统的最佳方法？
通过构建记录所有潜在攻击途径的威胁模型，您可以了解现有安全控制是否足以减轻攻击。威胁模型应直观展示产品的整个生态系统，包括软件开发以外的信息，如应用、系统、网络、分布式系统、硬件和业务流程。它应识别系统的所有弱点，并清楚解释攻击者如何利用它们，纳入相关真实攻击的信息，帮助您避免犯同样错误。
此信息将帮助您了解是否将精力集中在正确位置——即，当前减轻攻击的努力是否与攻击最可能发生的方式和位置一致。它将帮助您了解对系统的成功攻击会是什么样子，以及您是否充分准备好检测、响应和遏制它。良好的威胁模型应消除意外，使您的团队能够有计划地规划缓解措施。
5. 是否对所有员工进行身份验证和背景调查？
匿名开发在区块链行业很常见，但它阻碍了问责制、合同执行以及在区块链产品利益相关者之间建立信任。恶意行为者可以利用缺乏身份验证和背景调查来干扰产品开发、窃取资金或造成其他严重损害，而机构将没有或有限手段惩罚他们。近年来，朝鲜黑客使用虚假Linkedin账户申请真实职位，并冒充公司提供欺诈职位。这些做法直接导致了严重黑客事件，包括Axie Infinity的5.4亿美元损失。
因此，公司必须了解所有员工的身份并进行背景调查，包括使用公共化名的员工。公司还必须在访问控制和监控方面达到额外成熟度；例如，他们应根据员工的角色、背景和居住地（即考虑当地法律和管辖权）围绕运营安全做出谨慎决策。
6. 团队中是否有明确负责安全的成员？
团队中需要有人负责确保区块链系统的安全。针对区块链技术的威胁迅速发展，即使单个安全事件也可能是毁灭性的。只有 dedicated 的安全工程师才有时间、知识和技能集来识别威胁、分类事件和修复漏洞，这有助于在产品开发过程中建立信任。
理想情况下，此人将创建并监督一个 dedicated 的团队，将安全作为其工作职责的首要任务，最终拥有使组织对此列表中其他问题回答"是"的倡议。他们将监督跨部门工作，与开发人员、管理员、项目负责人、高管等合作，确保安全实践包含在组织的所有方面。
7. 生产系统是否要求使用硬件安全密钥？
凭据填充、SIM交换攻击和鱼叉式网络钓鱼几乎已抵消密码和SMS/推送双因素认证的保护能力。对于有价值处于风险中的高风险组织，防钓鱼硬件密钥是唯一合理选择。应使用特殊硬件密钥访问公司资源，包括电子邮件、聊天、服务器和软件开发平台。应特别小心保护生产中任何非常困难或不可能逆转的操作。
在组织内部使用这些密钥是 competent 链下基础设施管理的主要指标。如果这对您的IT团队来说似乎是一项繁重工作，请不要气馁。2016年，谷歌发布的一项研究表明，实施这些密钥很简单，在其5万名员工中很受欢迎，并且能有效抵御恶意攻击。U2F硬件令牌，如YubiKey和Google Titan，是硬件密钥的不错选择。
8. 密钥管理系统是否需要多人和物理步骤？
如果单个人维护控制您系统的密钥，他们可以在没有相关利益相关者共识的情况下单方面做出具有过大影响的更改。如果攻击者入侵其凭据，他们可以获得核心资产的完全控制。
相反，密钥管理应设置为需要多人共识或法定人数以及物理访问才能做出重要决策。多人完整性是高风险行业（如国防和传统金融）使用的有效安全策略；它们一举防范通过攻击者、内部威胁（例如恶意员工）和胁迫的入侵。在为基于法定人数的设置选择可信个体集时，选择既可信又适当激励的人至关重要，因为包括不合适或未对齐的个体会破坏系统对胁迫的抵抗力。通过额外要求物理密钥管理（例如使用物理保险箱或气隙设备存储密钥），您将显著降低任何个人或任何个人的密钥或密钥片段受损时的欺诈、盗窃、滥用或错误风险。
区块链组织应使用多签名或多方计算（MPC）控制和冷存储解决方案，至少用于持有大部分资产的中心钱包，或选择使用合格托管人，具体取决于特定法规和需求。解锁多签名钱包的密钥应存储在可信硬件上，例如硬件安全模块（HSM）、安全飞地或防篡改硬件钱包。
必须仔细部署和配置可信硬件以限制其攻击面。例如，绝不应可提取秘密，应避免网络连接。组织还应基于阈值、受影响钱包、目的地和发起交易的关键人员等参数建立严格的资金转移程序。
9. 是否为系统定义关键不变量并在每次提交时测试？
不变量是在程序执行过程中必须保持为真的条件。不变量可以针对整个系统（例如，任何用户都不应拥有超过总供应量的代币）或针对特定功能（例如，compute_price函数不能导致免费资产）。理解和定义不变量帮助开发人员明确系统的预期行为，并帮助安全工程师评估这些行为是否符合期望。这为安全测试提供了路线图，并减少了意外结果和故障的可能性。
定义不变量首先用简单英语记录关于系统的假设。这些不变量应涵盖广泛的功能和加密属性及其有效状态、状态转换和高级行为。规范良好的系统可能有数百个属性：您应首先关注最重要的属性，并持续努力改进其覆盖深度。为确保代码遵循不变量，必须在整个开发过程中使用自动化工具（如模糊测试器或基于形式方法的工具）进行测试。
10. 是否使用最佳自动化工具发现代码中的安全问题？
自动化安全工具是成功安全策略的基线要求。全自动化工具，如静态分析器，自动发现常见错误且维护需求低，而半自动化工具，如模糊测试器，允许开发人员更进一步检查逻辑问题。许多此类工具可用，但我们推荐使用顶级安全工程师积极使用的工具，并有已发现错误的 proven 记录。
Trail of Bits的智能合约安全工具使用最先进的技术，可集成到您的CI系统和编辑/测试/调试周期中。它们包括Echidna，一个用于Solidity智能合约的模糊测试器，和Slither，一个用于Solidity智能合约的静态分析器。在开发和测试期间自动化使用这些工具帮助开发人员在部署前捕获关键安全错误。
11. 是否进行外部审计并维护漏洞披露或漏洞赏金计划？
要识别区块链代码中的漏洞，仅依赖内部安全团队是不够的。相反，组织必须与拥有现代区块链技术深入知识的外部审计员合作，涵盖低级实现、金融产品及其底层假设，以及为现代应用提供动力的库、服务、桥和其他基础设施。（跟踪区块链安全事件的网站上充满了有时未为复杂变更寻求外部指导的公司。）
安全审计员帮助识别漏洞并提供重构开发和测试工作流的建议，以便这些漏洞不再出现。寻找审计时，重要的是澄清哪些组件在审查范围内，哪些被排除，以及应投入的努力水平，包括通过使用工具。通过理解审计的好处和限制，组织可以在审计结束后专注于需要改进的其他领域。
此外，漏洞披露或漏洞赏金计划可以通过为用户或研究人员在发现错误时联系您提供公开可访问的选项来增强您的安全态势。通过建立这些计划，组织显示了与独立错误猎人合作的意愿——没有这些计划，他们可能在社交媒体上公开披露错误甚至利用它们谋取私利。虽然这些计划提供许多好处，但考虑其限制和陷阱很重要。例如，漏洞赏金猎人不会提供提高系统安全成熟度或长期减少错误可能性的建议。此外，您的团队仍将负责分类错误提交，这可能需要持续的 dedicated 资源。
12. 是否考虑并减轻滥用系统用户的途径？
许多针对区块链的攻击，如网络钓鱼、Twitter/Discord诈骗和"杀猪盘"，试图欺骗用户在使用您的产品时采取不可逆转的行动。即使组织拥有最专业设计的安全系统来保护自己，其用户可能仍然脆弱。例如，区块链应用通常依赖加密签名，这增加了网络钓鱼尝试的可能性。开发人员应考虑使签名易于识别（例如使用EIP-712），并应创建和推广用户指南以最小化滥用风险。
为避免此类攻击，组织的安全策略应包括滥用测试，您的团队考虑攻击者如何造成社会、心理和物理伤害。理解重大财务或社会伤害的风险将帮助您的团队评估必要的流程和缓解措施。例如，如果您的协议用户包括高影响力利益相关者，如退休基金，基于协议费用创建保险基金可能有助于在入侵时使用户完整。
不要被Rekt
这12项控制措施不是决定您安全态势的唯一行动，但我们相信它们将增强每个开发人员的软件和运营安全，即使区块链技术快速创新。此测试不应作为一次性练习；这些问题具有持久价值，并应随着组织持续增长和开发新产品提供路线图。对这些问题的肯定回答并不意味着您将完全避免安全事件，但它可以使您和您的团队能够避开行业中最糟糕的标签：被rekt。
如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News