从一个格式化 JSON 的小工具，拖出 5 年的秘钥“垃圾场”

根据 The Hacker News 的报道和 watchTowr Labs 的原始研究，两款非常常用的在线代码/JSON 格式化工具：

JSONFormatter（jsonformatter.org）
CodeBeautify（codebeautify.org）

长期以来提供一个“保存并分享”的功能：开发者把 JSON 或配置贴进去，点一下 Save，网站会生成一个可分享的 URL，并把这条记录放到“Recent Links（最近链接）”页面。

问题在于：

1.这些“Recent Links”页面是公开的，没有任何访问控制；

2.URL 结构高度可预测；

3.还提供了一个 getDataFromID 之类的接口可以直接拉原始 JSON。

watchTowr 按照合法网页的公开内容去爬取这些 Recent Links，再通过接口拉取数据，结果拿到了一坨“惊喜”。

泄露的规模到底有多大？

综合多家媒体和原始报告，核心数字可以这样概括：

数据条目：
- 超过 80,000 条保存的 JSON/代码片段（“user pastes”）
数据体量：
- 超过 5GB 的结构化 JSON 数据。
时间跨度：
- JSONFormatter：约 5 年历史数据
- CodeBeautify：约 1 年历史数据

这些数据中包含的不是“demo 配置”，而是真正在生产环境使用的账号密码、API Key 和客户数据。watchTowr 甚至用内部工具对 8 万多条 JSON 做了自动解析和分类，确认里面是货真价实的“密钥垃圾填埋场”。

哪些工具有风险？不仅是 JSONFormatter 和 CodeBeautify

1.这次事件中被点名的两款工具

从各媒体报道来看，本轮曝光直接涉及的是：

JSONFormatter（jsonformatter.org） – 在线 JSON 格式化/校验工具，可保存并分享链接；
CodeBeautify（codebeautify.org） – 提供 JSON、XML、SQL 等多种格式的在线格式化/转换工具，同样有保存和 Recent Links 功能。

两家网站在研究公开后，已经临时关闭或调整了 “Save/Recent Links” 功能，对外声称在“改进功能”和增加内容过滤。

存档功能暂时禁用说明

到底泄露了什么？

watchTowr 给出的样本非常具体，媒体也做了二次整理。典型信息包括：

1.身份与访问类敏感凭证

AD（Active Directory）账号密码、LDAP 配置与凭证 – 直接决定整个域环境控制权；
数据库账号密码 – 各类生产库直接读写；
云环境（如 AWS）访问密钥 – 包括某国际金融交易所用于 Splunk SOAR 系统的 AWS 凭证；
代码仓库 Token（GitHub / GitLab 等） – 能拉取源代码，进而发现更多 hard-coded 密钥；
CI/CD 凭证 – Jenkins、GitLab CI 等流水线的 secret，用来下发配置和部署。

2.跟钱紧密相关的东西

支付网关密钥与配置 – Card payment gateway credentials，足以发起伪造交易或盗刷；
第三方金融接口的 API Key – 和上游清算、风控联动的接口权限。

3.各类密钥与私钥

私钥（Private keys）和证书口令 – 包含 TLS 证书的私钥密码、证书文件路径等；
某家网络安全公司暴露了“敏感配置文件的加密凭据 + SSL 证书私钥密码 + 内外网主机名/IP + 证书和配置文件路径”，相当于把一整套生产环境蓝图递给攻击者。

4.大量 PII 和业务配置

某银行的完整 KYC（Know Your Customer）信息导出，包括个人身份信息、公司资料等；
某政府机构上传了一段超过 1000 行的 PowerShell 脚本，用于新主机的自动化配置，虽然不一定包含明文密码，但里面详细写了内部端点、IIS 配置信息、加固策略和注册表键值——这些都是攻击者做内网渗透和横向移动的情报黄金。

5.行业覆盖面几乎是“全行业”

从 watchTowr 和多家媒体的总结来看，这批泄露数据涉及：

关键信息基础设施（能源、交通等）
各级政府机构
银行与非银金融机构
保险与证券（含国际交易所）
医疗与医疗保险
航空航天
电信运营商
零售、电商
科技与网络安全公司本身
教育、旅游等多数行业

简而言之：“谁都在用”，也“谁都在泄”。

网络安全公司的 JSON 代码片段 来源：watchTowr

攻击者怎么利用？“钓鱼”实验已经证明有人在扫

watchTowr 为了确认这些公开数据是不是已经被黑产盯上，专门做了一个“蜜罐实验”：https://www.bleepingcomputer.com/news/security/code-beautifiers-expose-credentials-from-banks-govt-tech-orgs/

使用 Canarytokens 生成伪造但格式正确的 AWS 访问密钥；
把这些假密钥写入 JSON 内容，通过 JSONFormatter / CodeBeautify 的保存功能生成链接；
链接设置为 24 小时过期，但在这 24 小时内保持可访问；
监控是否有人尝试使用这些 AWS Key。

结果：

在上传后的约 48 小时内，蜜罐系统就检测到几次尝试使用这些密钥的访问请求；
也就是说，即便前端“链接已过期”，实际存储在后台的数据仍有被黑产爬取和测试的可能。

多家媒体（BleepingComputer、SC Media、Times of India 等）都引用了这个实验结论，证明已经有攻击者在系统化地扫描这些网站里的“遗落密钥”

这次事件的本质问题：平台设计 + 人的习惯，谁更“背锅”？

1.平台的问题：把“保存分享”做成了“公开陈列架”

从安全架构角度看，JSONFormatter / CodeBeautify 至少踩了几个坑：

https://thehackernews.com/2025/11/years-of-jsonformatter-and-codebeautify.html

把用户“保存”的内容默认挂到公开的 Recent Links 列表；
URL 结构可预测、可穷举，为爬虫批量访问提供便利；
Back-end API 在无认证的情况下允许直接获取原始 JSON 内容。

这说明平台在设计时并没有把“密钥/生产数据”视为可能的输入场景，而是单纯当作“格式化示例数据”，缺乏“最小暴露面”思路。

2.更大的问题：开发者和运维把“线上敏感数据”当调试样本

但 watchTowr 在原文里面也说得很直白：真正的问题是“你们（开发者）把生产秘密往随机网站里扔”。https://thehackernews.com/2025/11/years-of-jsonformatter-and-codebeautify.html

从样本看，很多泄露 JSON 直接来自：

线上 Jenkins、CI/CD 的配置导出；
云平台（AWS Secrets Manager 等）的密钥导出；
生产环境的 KYC 导出、日志、完整 API 请求/响应。

这些东西从来就不应该被复制到任何第三方网站，更不应该通过“保存链接”转一手。

这也是本次事件在全球范围引起广泛讨论的原因——它暴露的不是某个厂商被黑，而是整个软件开发生态在处理“敏感数据 + 在线小工具”时的系统性不安全习惯

对企业的启示：怎么系统性补课？

1.制度与流程：把“在线工具”纳入安全基线

在开发、安全、运维规范中，明确禁止：
- 将生产环境的配置文件、密钥、数据库连接字符串、KYC 数据等，粘贴到任何无合约约束的第三方在线工具中；
- 包括但不限于在线格式化工具、在线日志查看器、在线 JWT/JWE/JWS 解码、正则表达式测试等网站。
在“数据分类分级”和“敏感信息处理规范”里写清楚：
- 生产数据只允许在受控环境（内网工具、本地 IDE 插件、自建服务）中处理；
- 如确需使用第三方 SaaS 工具，必须完成安全评估和合规审查。

2.技术侧：减少依赖外部“薅来的小工具”

优先选用本地或自托管版本的开发辅助工具：
- 本地 IDE 插件（VS Code、JetBrains 系列的 JSON/格式化插件等）；
- 自建代码片段管理/格式化服务，部署在内网，接入公司统一认证与审计；
- 对已有前端工具，可以简单包一层前端 JS 在本地浏览器处理，不把数据发到外网。
在 CI/CD 与代码仓库中部署Secret Scanning：
- 使用 TruffleHog、Gitleaks 等工具，对仓库和流水线配置做密钥扫描；
- 对“疑似密钥/Token 出现在代码或配置中”的情况进行拦截与告警。

3.意识与培训：把 JSONFormatter 这个案例直接写进“反面教材”

在开发者安全培训（SDL/DevSecOps 培训）中，专门用这次事件做案例：
- 让开发看见：“你以为只是为了排版做的 Copy & Paste，背后是 5 年历史的密钥公开陈列”；
- 讲清楚“在线工具 + 浏览器 + 无认证 API + 可预测 URL”的组合风险。
结合自家实际情况，列出内部常用的“危险在线工具清单”，要求：
- 这些工具只可用于脱敏数据 / demo 场景；
- 一律禁止粘贴生产环境数据；
- 在内网 Wiki 或开发手册中写清楚。