视频加载失败

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

1304 字
7 分钟
newapi Stripe Webhook 充值漏洞深度分析 - 空密钥绕过支付验证
微信二维码

联系方式 & 交流群

  • 微信: gzs-47

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



⚠️ 时效性提醒(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_idamount_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 是否为空,就会用空密钥验签,导致攻击者可以:

  1. 获取相同的 payload
  2. 用空密钥计算相同的签名
  3. 伪造出”合法”的请求

正确的防御姿势#

# ❌ 错误:未检查密钥是否为空
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 进行充值确认的业务

潜在风险#

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

修复建议#

立即措施#

  1. 升级版本:立即升级到 v0.12.10 或更高版本
  2. 检查配置:确认 StripeWebhookSecret 已正确配置(非空)
  3. 审计日志:检查历史 Webhook 记录,排查异常充值

长期加固#

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

代码修复示例#

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
}

总结#

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

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

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


参考资料#


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

文章分享

如果这篇文章对你有帮助,欢迎分享给更多人!

相关文章智能推荐
1
Stripe 协议支付自动化深度拆解:从 HAR 抓包到纯 API 全链路实现
技术分析完整拆解 Stripe 协议支付的技术实现:从浏览器 HAR 抓包逆向 Stripe Checkout Session 全流程,到纯 API 无浏览器实现 ConfirmationToken 创建、PaymentIntent 确认、3DS 验证挑战,再到 TLS 指纹对抗、代理池架构和反欺诈绕过。附 5 套不同技术栈的完整实现源码下载。
2
GPT Plus 订阅漏洞深度分析 - Google Play Billing 鉴权缺失导致 0 元订阅
漏洞分析技术拆解:通过 API 响应注入和 offerToken 内存替换两种方式,利用 Google Play Billing 与 RevenueCat 回调鉴权缺失实现 GPT Plus/Pro 零元订阅。
3
焚决 Claude — 一个油猴脚本如何撬开 Anthropic 的支付大门
漏洞分析深入拆解传说中的「焚决」——通过 Tampermonkey 油猴脚本劫持 checkout_capabilities API 响应,前端注入 cassia 支付流,配合随机德国 IBAN 实现 Claude Max/Pro 零元订阅。完整技术分析:Fetch/XHR 双通道拦截、SEPA CORE 直接借记清算机制、MOD 97-10 校验算法局限性、客户端信任边界漏洞的通用攻击框架与防御方案。
4
虚拟发卡系统回调伪造漏洞全链路拆解 — 从备份文件泄露到批量盗取卡密
漏洞分析深度分析一起针对 ACG-Faka + BEpusdt 的真实攻击事件:攻击者通过两条路径窃取支付密钥——下载 Web 根目录残留的备份文件,或利用 Nginx 配置错误直读 Config.php 源码——进而伪造合法回调通知批量盗取卡密。附官方安全公告、五站实测审计结果与完整防御方案。
5
0 PHP 白嫖 ChatGPT Plus — 跨区定价混淆攻击的完整技术拆解
漏洞分析深度拆解最近在群里疯传的 ChatGPT Plus 0 PHP 开通方法:日区注册 → 美区提 Token → 第三方工具生成 Checkout → 菲律宾 BIN 完成支付。跨区信号碎片化制造歧义,第三方工具利用异常路径注入零元参数。三种假说的完整技术分析。
随机文章随机推荐
Profile Image of the Author
47工作室
47工作室:记录技术实践与安全研究。
公告
欢迎来到 47工作室!微信:gzs-47
分类
标签
最新动态
站点统计
文章
39
分类
16
标签
165
总字数
121,285
运行时长
0
最后活动
0 天前
站点信息
构建平台
Local
博客版本
站点 vunknown
文章许可
CC BY-NC-SA 4.0