两层验证
我们把攻击自己的内部审查和独立的外部评估结合起来。
内部对抗性审查
独立团队用真实的攻击场景分多轮探查代码，并在数据库和服务器层面从结构上堵住发现的问题。
外部审查——AEGISonar
通过 WebEASM 的 AEGISonar，对我们的攻击面和网页漏洞做了独立的外部评估。
内部对抗性审查——我们是怎么做的
不是「我们写代码很小心」——而是真的试着闯进去。使用不同方法的独立团队分多轮并行审查代码，每个发现都要经过独立的反驳尝试、确认确实能被利用之后才算成立。
我们的方法
我们测试过的攻击场景
我们实际尝试了以下攻击，并确认它们在数据库和服务器代码层面都会被拦住。
✓绕过租户隔离
试图读取或写入另一家事务所的客户、文件或请求。不只是读取——写入（INSERT/UPDATE）也绑定在事务所↔客户关系上并被拦住。
✓纵向权限提升
试图从员工升为负责人，或从客户变成事务所成员。角色判定和邀请认领都在服务器和数据库强制执行。
✓劫持邀请链接
试图用不符的邮箱认领邀请。登录邮箱必须与受邀邮箱一致。
✓绕过 MFA
试图只凭密码获取数据。一旦设置了验证因素，数据库就要求 aal2（两步验证）会话。
✓滥用通知/邮件转发和注入钓鱼链接
试图通过通知路径注入伪造的登录链接。发件人身份和链接域名都固定为可信的值。
✓滥用注册流程
匿名大量调用注册 API 来破坏服务或抢占事务所地址。通过服务器路由、频率限制和付款会话绑定来拦截。
✓机密泄露、XSS、开放重定向
检查服务器机密是否泄露到浏览器、用户输入是否被当作脚本执行，以及重定向是否被滥用。
✓伪造短信回调
试图伪造短信入站回调来改变短信同意状态。通过强制签名验证来拦截。
确认属实的问题都在数据库策略和服务器代码层面被堵住了，大多是在真正的客户使用之前。
坦诚的界线
安全是一个没有「完成」的持续过程。我们的内部审查基于静态分析和攻击场景，并辅以外部的 AEGISonar 评估。随着客户增多，我们会继续扩大测试范围。与其声称完美，我们选择坦诚说明验证了什么、是怎么验证的。