移动支付网消息：根据国外安全研究团队Ransomnews发现的信息，支付平台Stripe超过5万枚商户API密钥竟散落在公开代码库、构建日志和配置错误的Web服务器上，其中相当一部分至今仍然有效。

更值得注意的是，一个包含659个商户实时密钥及约35GB客户与支付数据的数据集，于8月18日还出现在地下数据交易论坛中。

实验：从“发现密钥”到“完成扣款”需17小时

Ransomnews是海外一家独立开源情报（OSINT）网络安全研究团队，主打勒索软件、网络黑产、数据泄露生态追踪，并非传统大型安全厂商，以公开情报分析、地下论坛监测、威胁人物画像为核心产出，在全球勒索威胁情报社区有较高曝光度。

拿到一批活跃的Stripe密钥后，Ransomnews进行模拟攻击实验。

结果显示，在找到有效的密钥后，只需17个小时就能完成一整套操作链，从访问商户的客户名单、获取存储的支付方式信息、创建欺诈性的支付链接、发起一笔测试扣款等等。这也意味着通过这些有效的Stripe密钥可获得完整的API访问权限，攻击者甚至还能在商户启用了Stripe Connect的情况下触达关联账户。

这次Stripe密钥泄露最大的源头来自GitHub仓库。有些是公开仓库，有些则是本该私有化却不小心设为公开的数据；其次是GitHub Actions的构建日志。当工作流为了调试而打印环境变量时，任何没有被正确遮蔽的密钥都会明文出现在日志中，任何有仓库访问权限的人都能查看；第三是配置错误的Web服务器。Ransomnews发现了超过3000台服务器暴露了Stripe相关字符串，其中大约12%的密钥还能直接对Stripe API生效。

至于那出现在地下数据交易论坛中的659个商户的密钥数据集，其确切来源则仍不清楚。

需要指出的是，Ransomnews在发布研究前已将暴露情况报告给Stripe。报告还明确强调，Stripe平台本身并未被入侵，这些密钥本身属于商户，是从商户侧的开发和运维环节中流出。

防护机制问题出现在哪里？

事实上，针对商户侧的开发和运维环节，Stripe也并非没有防护措施。正常情况下，Stripe通过GitHub的合作伙伴计划提供自动密钥扫描，一旦在公开仓库中发现Stripe密钥，就会发出标记，甚至在商户选择加入后仍可以触发自动撤销。

但由于opt-in率偏低（指在需要主动授权的场景中，实际同意的用户数占比）、覆盖盲区（扫描只盯公开仓库，私有仓库、构建日志、Web服务器等被忽略）等因素，防护机制未能生效。

更微妙的是，Ransomnews发现一些商户在GitHub暴露事件后确实更换了密钥，但旧密钥仍然处于活跃状态。其中原因是Stripe在密钥轮换时不会自动撤销旧密钥，除非用户明确手动删除。这意味着"更换"并不等于"作废"，旧密钥仍然可以被人利用。

Ransomnews给出的修复建议并不复杂，但每一条都需要商户主动执行而不能光依赖Stripe平台来兜底。

首先，商户需要拿自己的版本控制历史做一次审计，看看有没有密钥曾经被提交过；第二，更换任何曾接触过公开仓库、构建日志或未受保护配置文件的密钥；第三，对于不需要完整账户访问权限的集成，启用Stripe的限制密钥；第四，开启Stripe Radar的异常扣款检测规则，这样即使密钥已经被人拿走，系统也能提前标记可疑活动。

写在最后

这次事件的本质并不奇怪，开发者把密钥写进代码、提交到仓库、打印进日志，这些都是安全社区反复警告了多年的"老问题"，只是Stripe的支付场景让这些问题显得更有分量。

Stripe是全球电商、SaaS和订阅制企业最常用的支付接口之一，密钥背后是真实的客户数据、真实的资金流动和真实的退款通道。5万枚密钥散落在公开空间，意味着开发环境的安全疏忽可能直接转化为欺诈风险，攻击者甚至不需要入侵Stripe，不需要攻破任何系统，只需要在GitHub上翻一翻代码，就能拿到通往别人收银台的钥匙。