博客
2020 年 7 月 28 日
API 密钥日志泄露
作者 André Arko
API 密钥日志泄露
摘要
2018 年 10 月至 2020 年 7 月期间，407 个用户 API 密钥无意间通过 HTTP 日志发送至第三方服务。数据对公众可用，但根据该服务的查询日志显示，从未有人查询任何已发送的 API 密钥。
出于高度谨慎的原因，我们已重置所有 407 个 API 密钥。我们还 更新 API 密钥系统，以便减少将来的此类问题发生的几率。
事件经过
RubyGems.org 于 2018 年 10 月开始将 Fastly 和 Nginx 访问日志发送至 Honeycomb。Honeycomb 向 RubyGems.org 数据集提供公共访问权限，而且 其中有许多有关 Ruby 生态系统 有用而有趣的数据。RubyGems.org 在将数据发送至 Honeycomb 之前会清除 PII（例如客户端 IP 地址），并且 Honeycomb 保留数据的时间长达 60 天。
RubyGems.org 团队于 2020 年 7 月 18 日星期六发现，一些 API 密钥通过发送至 Honeycomb 的事件日志公开访问。发现此情况后，我们立即停止向 Honeycomb 发送新数据，并取消了对该数据集的公共访问权限。
为何如此糟糕
从本质上来说，RubyGems.org 用户 API 密钥是用户凭证。如果恶意开发者能够获得你的 API 密钥，他们就有可能使用该密钥来移除你的 gem，或推送新版本你的恶意 gem。
请务必注意，版本不可变，因此在合法发布版本后，即便使用适当（或窃取的）凭证也无法对其进行修改。此外，如果你为 API 访问启用了双重身份认证，那么窃取的 API 密钥不足以获得 gem 推送、移除、所有者和登录命令的访问权限。
谁受到了影响
仅在 RSS 阅读器中订阅其个人仪表盘 RSS 源的用户可能会受到影响。
泄露的 API 密钥都已在自定义仪表盘 RSS 源的查询字符串中发送。遗憾的是，许多 RSS 客户端都无法发送授权头，因此在 URL 中发送令牌是许多 RSS 客户端查看其个性化仪表盘的唯一途径。
当我们最初设置 Honeycomb 集成时，忽视了此功能，仪表盘 GET 请求中的 API 密钥未从日志中清除。
我们的应对措施
我们在过去 60 天内扫描了整个 Honeycomb 数据集，并找到了 155 个无意中发送到 Honeycomb 的密钥。我们立即重置了所有这些密钥。然后，在 Honeycomb 团队的帮助下，我们查看了完整的 Honeycomb 查询历史记录，并确认从未有过任何查询在任何时间点搜索 API 密钥。最后，我们解压缩了自 2018 年 10 月以来的所有 HTTP 日志，并找到了另有 252 个曾经发送到 Honeycomb 的 API 密钥。我们也已经重置了这些 API 密钥。
总共有 407 个 API 密钥被发送到了 Honeycomb（在总共 147,849 个 API 密钥中）。我们已重置了所有 407 个密钥，并向所有密钥被重置的用户发送了电子邮件。
您需要做什么
如果您自 2018 年 10 月以来在 URL 中使用过带有 API 密钥的自定义仪表盘 RSS 源，则您应该检查您的宝石，以确保在 2018 年 10 月至 2020 年 7 月期间没有添加未经授权的版本。
自 2019 年 8 月以来，每个宝石推送都会向该宝石具有所有者权限的所有帐户触发一封通知电子邮件。如果您没有收到任何可疑通知，则您只需要验证您从 2018 年 10 月到 2019 年 8 月的宝石。
任何受此泄露影响的人的 API 密钥都已重置。如果您想要极其谨慎，您可以再次重置您的 API 密钥。每个人都可以轻松重置自己的 API 密钥：访问 rubygems.org/profile/edit，并查找“重置我的 API 密钥”按钮。
下一步
- 如上所述，我们已重置了所有发送到 Honeycomb 的 API 密钥。
- 我们不再允许通过查询字符串参数进行身份验证的 API 操作。这是一个重大更改，但我们认为这对于构建安全的生态系统是必要的。
- 我们很快会更改 RSS 源，使其拥有自己的密钥，并且没有访问 API 的权限，从而降低使用 RSS 源的风险。
- 一旦我们确信我们已经过滤了数据中的 API 密钥，我们将重新启用 Honeycomb 集成。