1,033 个正在使用的 Stripe 密钥从 669 家供应商处泄露,原因是 .env 文件和调试日志在公网上处于可访问状态。这些密钥允许任何人创建扣款、提取发票并获取客户详情——这种泄露可能在几分钟内耗尽资金并毁掉声誉。
泄露是如何发生的
开发人员通常将配置数据(数据库密码、API 令牌和 Stripe 密钥)存储在名为 .env 的文件中。该文件与源代码并存,并在运行时被读取,以确保密钥不会进入代码库。只有当服务器从不提供以点(dot)开头的文件时,这种做法才有效。在这种情况下,配置错误的 Web 服务器(包括 Nginx 和 Apache)允许对 “/.env”、“/.env.example”、“/.git/HEAD” 以及自定义的 “/debug” 端点的请求返回带有 200 OK 状态的原始文件。
此次泄露并非由 Stripe 平台的漏洞或任何特定电子商务插件的缺陷引起。这纯粹是本应对外界不可见的文件被直接暴露了。
为什么这种暴露至关重要
Stripe 密钥实际上是商户支付通道的主密码。任何持有它的人都可以:
- 对存储的卡片进行任意扣款
- 检索发票和付款历史记录
- 提取个人数据——姓名、电子邮件、电话号码、家庭地址、IP 地址
- 使用促销代码进行免费或折扣购买
泄露的数据集包含了上述所有内容,此外还包括揭示每个供应商赚取了多少金额的付款详情。对于企业而言,直接风险包括产生拒付(chargebacks)的欺诈交易、失去客户信任,以及根据 PCI-DSS、GDPR 或其他数据隐私法规可能面临的罚款。长期成本可能更高:法律费用、补救费用以及可能永远无法恢复的品牌声誉受损。
快速测试:你的 .env 是否已暴露?
打开终端,并将 yourdomain.com 替换为你自己的主机名:
for p in "/.env" "/.env.example" "/.git/HEAD" "/debug"; do
echo -n "$p -> "
curl -s -o /dev/null -w "%{http_code}\n" "https://yourdomain.com$p"
done
每一行都应返回 403(禁止访问)或 404(未找到)。如果返回 200,则意味着该文件可以被公开读取——这是一个需要立即处理的关键安全事件。
立即补救步骤
1. 在 Web 服务器端拦截点文件 (dotfiles)
- Nginx – 添加一个 location 块,拒绝任何对以点开头的文件请求。
- Apache – 在
.htaccess中使用FilesMatch指令,对以点开头的文件返回 403。
2. 加固你的 Docker 工作流
- 将
.env添加到.dockerignore中,这样该文件就不会被复制到镜像中。 - 避免对任何包含密钥的文件使用
COPY指令。
3. 更换所有受损密钥
- 登录 Stripe Dashboard → Developers → API keys。
- 立即生成新的密钥并撤销旧密钥。
4. 采用最小权限密钥
- 停止对所有操作使用单一的密钥。
- 创建仅允许所需操作的受限密钥(restricted keys)——例如,结账服务需要创建 payment intents 的权限,但不需要发放退款或查看付款详情的权限。
5. 清除旧密钥的所有副本
- 扫描 CI/CD 日志、构建产物(artifacts)和备份存档。
- 对你的 Git 历史记录运行 Gitleaks 或 TruffleHog 等密钥扫描工具。
密钥泄露并不会因为你从服务器上删除了文件就消失;它会永远留在下载了它的人手中。更换密钥是让被盗数据失效的唯一方法。
在修复之外:构建更安全的流水线
- 自动化扫描 – 将密钥检测集成到每个 pull request 和 CI 任务中。
- 配置管理 – 将密钥存储在专门的保险库(如 HashiCorp Vault、AWS Secrets Manager)中,并在运行时注入,而不是依赖静态文件。
- 访问审查 – 定期审计哪些 Stripe 密钥处于活动状态,以及它们拥有哪些权限。
这些实践降低了单个配置错误的服务器暴露整个支付基础设施的可能性。
后续关注点
安全社区已经开始使用相同的方法寻找其他泄露的密钥。随着自动化扫描器在网络上爬取包含 Stripe 令牌的 “/.env” 文件,预计会有更多披露。Stripe 可能会针对密钥更换频率发布更多指南,并建议在高风险操作中使用受限密钥。
总结
如果一个 dotfile 可以通过浏览器获取,那么你的支付系统就已经失陷了——在欺诈行为波及你的账本之前,请立即封锁该文件、轮换密钥,并重新设计你的机密处理工作流。
