0 PHP 白嫖 ChatGPT Plus — 跨区定价混淆攻击的完整技术拆解

Step 1：日本节点注册 OpenAI 账号#

挂 JP 代理，开一个干净的浏览器 Profile（指纹浏览器或者 Chrome 新 Profile），去 OpenAI 官网正常注册，邮箱验证，登录确认。

此时你的账号状态：

1
account.locale = "ja-JP"
2
account.billing_country = "JP"
3
account.currency = "JPY"

OpenAI 在注册时根据你的 IP 地理位置初始化账号的计费区域。这一步的目的不是”要日本”本身，而是要一个非美区的初始定价锚点。

Step 2：切美国节点，提取 Access Token#

保持同一个浏览器 Profile，VPN 切到 US 节点，重新登录刚才注册的账号。然后新标签页打开：

1
https://chatgpt.com/api/auth/session

浏览器返回一个 JSON，里面有 accessToken 字段——一个标准 JWT。复制保存。

此时你的 session 状态出现了第一层矛盾：

1
account.billing_country = "JP"  ← 注册时写入，持久化在 OpenAI 数据库
2
session.ip_country = "US"       ← 当前 IP 推断，存在 session/edge 层

Step 3：第三方工具生成 Checkout 链接#

打开某个第三方”CDK 提炼”工具站点（这类工具本质上就是一个 AT → Stripe Checkout Session 的代理），把 Access Token 粘进去，点生成。

工具返回一个链接，格式：

1
https://chatgpt.com/checkout/openai_llc/oaics_xxxxxxxxxxxxxxxxxxxxx

oaics_ 是 OpenAI 的 Stripe Checkout Session ID 前缀。这个 session 是 OpenAI 后端基于你的 AT 创建的，包含了产品、价格、货币等信息。

关键问题来了：这个 Checkout Session 的 currency 和 amount 是怎么决定的？

Step 4：打开链接，惊喜时刻#

在美国节点下打开这个 oaics 链接。Stripe 结账页面加载出来，你看到：

1
ChatGPT Plus
2
₱0.00 PHP / month

菲律宾比索。零元。

填入指定 BIN 的卡片信息（523686 或 4513），美国账单地址，提交。

Stripe 收了一笔 0 元交易，OpenAI 后端确认 checkout session 成功，权益生效。回到 ChatGPT 首页，左上角已经是 Plus 了。

假说一：第三方工具在创建 Checkout Session 时注入了零元参数（最可能）#

OpenAI 的 /backend-api/payments/checkout 接口接受多个参数来创建 Stripe Checkout Session。如果这个接口接受客户端传入的 discount、coupon、promotion_code 或类似参数，且后端没做资格校验——工具直接传了一个 100% 折扣的 coupon code 或者 amount_override: 0。

这和之前 RevenueCat 文章里分析过的 eligible_promo_campaigns 注入如出一辙：客户端声称”我有优惠资格”，后端不校验就信了。

1
// 工具的真实请求可能长这样
2
body: JSON.stringify({
3
  plan: "plus",
4
  promotion_code: "某个内部免费试用码",
5
  // 或者
6
  billing_country: "PH",
7
  currency: "php",
8
  // 或者更直接的
9
  price_override: 0
10
})

JP 注册 + US 登录制造的区域歧义，可能不是直接触发 0 元的原因，而是绕过风控检查的前置条件——当账号区域和 IP 区域不一致时，后端对 checkout 参数的校验逻辑可能走入了一个宽松的分支。

假说二：跨区信号冲突导致定价路由进入异常分支#

当 OpenAI 创建 Stripe Checkout Session 时，面前有至少四个区域信号：

正常场景下这四个信号一致——美国人在美国用美国卡买东西，直接查 US 价格表。

但当 JP ≠ US ≠ PH 三个信号同时存在时，定价系统需要做一个选择。如果选择逻辑是 if (account.country != ip.country) { use card.country } 这种优先级策略，而 PH 价格表虽然存在但在某个子路径（比如”非本地注册用户+跨区IP”的特殊定价分支）中没有配置——就可能在这个特殊分支里 fallback 到 0。

换句话说：PH 的主价格表有值（₱990），但某个异常处理路径的价格映射没覆盖到 PH，攻击者通过区域信号碎片化精确命中了这条路径。

假说三：Stripe Checkout Session 的 line_items 被工具篡改#

Stripe checkout.sessions.create 的 line_items 参数包含 price 或 price_data。如果 OpenAI 的接口允许客户端指定 price_data.unit_amount（哪怕是间接的），工具就能在创建 session 时直接把金额写成 0。

1
line_items: [{
2
  price_data: {
3
    currency: "php",
4
    unit_amount: 0,        // 直接指定 0
5
    product: "prod_xxx",
6
    recurring: { interval: "month" }
7
  },
8
  quantity: 1
9
}]

这种情况下 PH BIN 的作用不是”触发 PH 价格表”，而是让 currency 字段说得通——如果你传 currency: "php" 但卡是 US 卡，Stripe 可能会有额外的 currency mismatch 警告。PH 卡 + PHP 货币是自洽的。

为什么是 PH BIN？#

无论哪种假说，流传的两个 BIN 都有其作用：

523686 开头的卡填入 Stripe 表单时，Stripe 内部标记 payment_method.card.country = "PH"。这个信号在整个支付流中传播。PH BIN 的作用至少有两个：

1. 让 PHP 货币的 checkout session 能正常完成——卡的发行国和结账货币匹配
2. 可能绕过 OpenAI 的 card-country vs account-country 风控规则——PH 卡付 PHP 金额在 Stripe 层面是”正常交易”

BIN 在支付流中的角色#

BIN（Bank Identification Number）是卡号的前 6-8 位，编码了发卡行、卡网络、卡类型和发行国等信息。Stripe 在收到卡号的前 6 位时就能确定：

1
523686 → Mastercard / Philippines / Credit / 某发卡行

这个信息会被写入 payment_method.card.country，并在整个支付流中传播。

为什么必须是 PH BIN？#

PH BIN 的作用不是”触发一个空的价格表”——PH 价格表是存在的（约 ₱990/月）。

更可能的解释是：

1. 货币匹配：如果工具创建的 Checkout Session 指定了 currency: "php"，那么 PH 发行的卡才能让 Stripe 的 currency-card 一致性检查通过。US 卡 + PHP 货币会触发额外的风控审查。

2. 风控绕过：OpenAI/Stripe 的风控系统可能对”card country = PH + checkout currency = PHP”这个组合判定为”正常的本地交易”，不会触发跨境支付的额外校验。而如果用 JP 卡或 US 卡来付一笔 0 PHP 的订单，风控更容易拦截。

3. AVS 绕过：PH 卡不走 Stripe 的 AVS 地址校验，所以填什么地址都行——这降低了被拒的概率。

523686 和 4513 是经过实测确认能被 Stripe 正确识别为 card.country = "PH" 的 BIN 段。不是所有 PH BIN 都行，因为某些 BIN 可能已被 OpenAI/Stripe 的风控规则标记或黑名单。

为什么要填美国账单地址？#

这步看起来矛盾——卡是菲律宾的，地址填美国？

原因是 Stripe 的 AVS（Address Verification Service）只对美国和英国的卡做地址校验。PH 卡不走 AVS，所以你填什么地址都无所谓——但如果你填 PH 地址，可能触发 OpenAI 的额外风控逻辑。填 US 地址是为了”看起来正常”，降低被风控拦截的概率。

修复方案（从简单到全面）#

Level 1：Checkout Session 金额校验

1
def create_checkout_session(user, plan):
2
    price = get_price(plan, resolve_country(user))
3
    if price["amount"] == 0 and plan != "free":
4
        raise ValueError("Zero-amount checkout for paid plan")
5
    # ...

付费产品金额为 0 时直接拒绝创建 session。这应该是支付系统的基本不变量。

Level 3：区域一致性校验

1
def resolve_country(user):
2
    signals = {
3
        "registration": user.billing_country,    # JP
4
        "session_ip": geoip(user.current_ip),     # US
5
        "card_bin": None,  # 创建 session 时还不知道
6
    }
7
    # 如果注册地和 session IP 不一致，以注册地为准
8
    # 不让 card BIN 覆盖定价区域
9
    return signals["registration"]

定价的 country 由一个确定性函数决定，不受 card BIN 影响。Card BIN 的 country 只用于风控信号，不参与定价。

Level 4：Webhook 后置校验

1
def on_checkout_completed(event):
2
    session = event.data.object
3
    if session.amount_total == 0 and session.mode == "subscription":
4
        # 0 元订阅？不对劲
5
        stripe.Subscription.delete(session.subscription)
6
        alert("Zero-amount subscription detected", session)

即使 Checkout Session 创建时金额为 0，在 checkout.session.completed webhook 里也要做最终校验。这是最后一道防线。

攻击模型#

1
victim_system.pricing = f(country)
2

3
country = resolve(
4
  signal_1: registration_country,  ← 攻击者控制（注册时选择 VPN 节点）
5
  signal_2: session_ip_country,    ← 攻击者控制（登录时选择 VPN 节点）
6
  signal_3: card_bin_country,      ← 攻击者控制（选择特定 BIN 的卡）
7
  signal_4: browser_locale,        ← 攻击者控制（浏览器设置）
8
  signal_5: billing_address,       ← 攻击者控制（表单填写）
9
)

所有五个信号都由攻击者完全控制。如果 resolve() 函数对歧义输入的处理不当——比如进入异常分支后放松了参数校验，或者 fallback 逻辑允许客户端覆盖定价——攻击者就能把定价推入非预期状态。

防御原则#

原则一：定价权归一

1
pricing_country = user.billing_country  // 只有一个来源，注册时确定
2
// card BIN、IP、locale 都不参与定价决策
3
// 只作为风控辅助信号

原则二：Checkout 参数不可客户端覆盖

1
# 服务端决定 price、currency、amount
2
# 客户端/第三方传入的 discount、coupon、price_override 一律忽略
3
# 只接受服务端白名单内的 promotion_code，且校验账号资格
4
checkout_session = stripe.checkout.Session.create(
5
    line_items=[server_determined_price],  # 不接受客户端 price_data
6
    discounts=[],                          # 不接受客户端 coupon
7
)

客户端能影响定价 = 攻击面。

原则三：零元红线

1
if checkout.amount == 0 and plan.type == "paid":
2
    REJECT()  // 无条件拒绝

付费产品不可能合法地出现 0 元。这应该是一个硬编码的不变量，不依赖任何业务逻辑。