一、事件来龙去脉
爆发时间线
7 月 26 日，技术社区流传一套“零元开通 Claude Max 20x"的教程。该套餐为 Anthropic 顶级订阅，原价约 180 欧元/月，提供 20 倍于 Pro 版的用量及 Fable 5 等高级功能。消息迅速在各大社交平台扩散，甚至出现批量注册小号及倒卖教程的灰色产业链。
7 月 27 日，Anthropic 紧急修复漏洞，关闭 SEPA 支付入口并失效相关脚本。随后平台启动严厉风控，对曾登录漏洞操作设备的账号进行无差别封禁，并标记设备硬件信息，导致后续新注册账号极易受限。
攻击手法
攻击者利用不足 200 行的 Tampermonkey 脚本，通过以下步骤实现免单：
- 拦截 API 响应：劫持
GET /api/organizations/{org_id}/subscription/checkout_capabilities接口，将返回的checkout_flow: "stripe"篡改为checkout_flow: "cassia"（Anthropic 内部用于欧洲 SEPA 直接借记的标识）。 - 前端渲染切换：前端接收篡改数据后，支付页面由信用卡表单变为 IBAN 输入框。
- 填写虚假信息：利用生成器创建格式合法的德国 IBAN 及随机地址姓名填入表单。
- 直接解锁权限：系统未实际扣款即判定订阅成功，账号立即解锁全部 Max 20x 权限。
二、漏洞根因复盘
本次事故源于“客户端信任边界失效”与"SEPA 异步扣款机制被误用”两个缺陷的叠加。
缺陷一：前端驱动支付流，服务端零校验
Claude 支付架构将通道选择权完全交由前端。checkout_capabilities接口返回的字段直接决定支付流程，而服务端在接收提交时未重新校验用户资格。这意味着前端可随意声明使用 SEPA 流程，后端照单全收，缺乏任何拦截机制。
缺陷二：SEPA 异步扣款与权益过早发放
SEPA 直接借记机制为“先发起扣款，后银行结算”。提交时系统仅验证 IBAN 格式（MOD 97-10 校验），不验证账户真实性、归属权及资金状况。Stripe 文档明确指出 SEPA 扣款需数天完成，期间状态长期处于processing且可能失败。
致命错误在于：Claude 支付状态机在扣款仍处于processing状态时，误判为成功并立即发放高价值订阅权限。
完整攻击链路
油猴脚本篡改 checkout_capabilities 响应
↓
前端渲染 SEPA 支付表单（原本不应对该用户开放）
↓
用户提交随机生成的虚假德国 IBAN
↓
后端接受 SEPA 订单（未校验用户地区/资格）
↓
SEPA 扣款进入 processing 状态（未实际扣款）
↓
支付状态机误判为成功 → 立即发放 Max 20x 权益
↓
用户零成本获得价值 €180/月 的订阅权限
三、责任方分析
主要责任：Anthropic（P0 级生产事故）
- 架构设计缺陷：违背“前端不可信”原则，将影响付费逻辑的决策权下放给前端。
- 业务规则校验缺失：后端未独立核验用户使用 SEPA 支付的资格，盲目接受客户端指定方式。
- 状态机设计错误：在异步扣款未清算完成前提前发放权益，属于典型的“先给货、后收钱”反模式。
- 风控预警缺失：面对短时间内大量异常德国区 SEPA 订单及随机 IBAN 模式，系统未触发自动告警。
次要责任与边界
攻击者利用漏洞牟利属恶意滥用，但根源在于系统设计缺陷。Stripe 作为支付处理方，其 SEPA 产品行为符合规范，问题在于 Anthropic 对支付状态回调的消费逻辑错误。
四、行业警示与预防措施
风险警示
任何同时提供同步支付（信用卡）和异步支付（SEPA、银行转账等）的 SaaS 平台，若将支付通道选择权交给前端，均面临同类风险。攻击模式可迁移至任何存在“信任边界错位 + 异步确认间隙”的场景。
预防措施清单
- 支付流决策服务端闭环：
checkout_flow等关键字段必须由服务端根据用户地区、账号状态及风控信号独立计算。前端仅作渲染，支付提交时后端必须二次校验资格。 - 异步支付延迟开通权益：
对于需清算的支付方式，应设置“处理中”临时状态，待 Stripe webhook 回调确认扣款成功后再激活完整权益。
- API 响应签名：对关键接口响应进行 HMAC 签名，前端消费前验签，大幅提高篡改门槛。
- IBAN 实时验证：接入 SWIFT gpi 或各国央行验证服务，在提交时进行账户存在性校验，而非仅依赖本地格式校验。
- 建立支付异常监控：针对同一设备多账号 SEPA 支付、连续随机 IBAN 模式、新账号高额异步支付等场景，自动触发人工审核或风控拦截。
- 客户端安全加固：重点保护信号接口，采用混淆和完整性校验技术，并在敏感操作中增加服务端会话验证。
五、事件余波
Anthropic 的处置方式引发争议：无差别封号导致正常用户连带受害；设备黑名单机制使得同一设备无法注册新号；一刀切限制新用户权限而非针对性封禁。此次 P0 级事故不仅造成数千万美元直接损失，更严重损害了用户信任，迫使平台长期收紧风控体系。这也再次印证：专业的事应交给专业的架构设计，否则代价惨重。