一次侦察数据复盘：如何在“废弃”测试域名中发现大规模PII泄露漏洞

本文仅用于网络安全研究与学习，请勿将相关技术用于任何非法活动。

声明：本文搬运自互联网。

漏洞类型：IDOR (不安全直接对象引用)

在本文中，我将分享自己如何通过深入复盘旧的侦察数据，分析其中的 JavaScript 文件，最终在一个看似无关的域名中发现了一个隐藏的攻击面。这个最初像极了测试环境的站点，暴露出一个严重的 不安全的直接对象引用 (IDOR) 漏洞，能够通过 API 端点泄露高度敏感的个人身份信息 (PII)。

该漏洞使未经授权者能够访问敏感的用户信息，包括姓名、电话、地址及其他机密数据。攻击者仅需篡改 API 请求中的对象标识符，即可检索属于其他用户的记录，这大大提升了该问题的潜在危害。

这次发现的特别之处在于其过程。它并非源于常规的手动探测，而是通过分析历史侦察数据、探索 JavaScript 文件、识别侦察中标记的异常域名，并利用搜索引擎索引来挖掘隐藏的 API 端点而实现的。这证明了，通过开源情报 (OSINT) 和创造性侦察来扩展攻击面，往往能发现自动化扫描或表面测试可能漏掉的漏洞。

本文将带你了解：

• 如何通过分析旧的侦察数据来发现新的攻击面。
• 为什么侦察中发现的“异常”域名可能是漏洞的宝库。
• Google 搜索技巧如何帮助我们定位隐藏的 API 端点。
• 一个简单的 IDOR 漏洞如何演变成大规模 PII 泄露事件。
• 在 API 安全测试中，直觉与坚持的重要性。

现在，让我们一起来看看这个漏洞是如何被发现、测试的，以及我们能从中吸取哪些教训。

开端：一切是如何开始的

由于工作繁忙和搬家，我暂停了一段时间的漏洞赏金活动。但最终，那种想要重新开始的熟悉冲动又回来了。任何在这个领域待久了的人都知道，好奇心永远不会真正消失。一旦你不再以安全的视角审视应用程序，就会觉得少了点什么。

但这次，我决定换个思路。

我没有像往常一样直接开始手动测试，而是觉得重新审视之前积累的侦察数据会很有趣。随着时间的推移，侦察脚本会收集大量信息——域名、子域、JavaScript 文件、端点等等，其中很多都未被深入探索。有时候，宝藏就藏在你已经拥有但从未仔细分析过的数据里。

于是我开始挖掘。

我逐行检查了过去收集的域名、爬取的端点和 JS 文件，试图理解应用程序的内部逻辑。大部分内容都是预期的 API 参考、配置文件和标准路由。但很快，一些不寻常的东西引起了我的注意。

有一个域名不太符合常规模式。

为了讨论方便，我们假设主域名类似 redacted.com。但在我的侦察数据中，脚本还记录了另一个域名：stageredacted.com。有趣的是，它并非 stage.redacted.com 这样的典型子域，而是一个完全独立的域名，却又似乎与主域属于同一生态。

对于漏洞赏金猎人来说，发现新的或被忽略的攻击面，就像在你以为已经测绘完毕的建筑里发现了一个暗门。我的好奇心被瞬间点燃了。

我在浏览器中打开了这个域名。

404 未找到。

乍一看，这没什么大不了。但有经验的研究者知道，在一个陌生域名上遇到 404，有时可能是个好迹象。这通常意味着基础设施存在，只是关键端点没有暴露在根路径上。

于是我开始测试。

我尝试了目录模糊测试、探测常见 API 路由、检查典型的开发端点，并试了各种路径。但多次尝试后，依然没有发现什么有趣的东西。所有请求要么返回空响应，要么就是那个熟悉的 404 页面。

这时，很多研究者可能就转向下一个目标了。

但我总觉得这个域名哪里不对劲。

我没有放弃，而是决定尝试另一种搜索引擎方法。

搜索引擎有时会索引开发者本不打算公开的端点。所以我运行了一个简单的 Google 搜索语法：

site:*.stageredacted.com

事情就是从这时开始变得有趣的。

搜索结果中出现了几个API 接口。它们显然是测试环境的一部分，直接访问时似乎会返回测试或演示数据。我开始尝试修改这些接口中的参数值，观察 API 的行为。

最初，返回的响应只包含示例或演示记录，没有敏感信息，也没有任何看起来像生产数据的东西。乍看之下，这似乎不足以构成报告。许多测试环境都包含模拟数据，这里看起来也一样。

但随后我脑海中闪过另一个想法。

如果这些相同的端点在暂存环境之外的其他地方行为不同呢？

译者注：例如，如果发现了 https://stageredacted.com/api/v1/user?userid=xxx，可以尝试用相同的路径和参数去请求 https://redacted.com/api/v1/user?userid=xxx。

出于好奇，我尝试向主生产域名发起类似的请求。遗憾的是，这没有成功。响应要么报错，要么返回空结果。

然而，我的直觉告诉我，里面还有更深的东西。

于是我尝试了另一种方法：自动化地向生态内的多个子域发起请求。我写了一个简单的脚本，以编程方式测试端点，希望 API 在基础设施的某个环节能有不同的响应。

但是，一切努力都白费了。

到此为止，最简单的结论就是：此路不通。

然而，当我仔细查看脚本输出时，我注意到了一个虽小但重要的问题：脚本在请求中使用了随机或占位符 ID。如果 API 需要有效的标识符，这就能解释为什么所有请求都失败了。

所以我决定手动测试。

我将占位符 ID 替换成从主应用程序获取的真实标识符，然后重新发送了请求。

从那时起，一切都变了。

某个特定子域上的一个 API 端点突然返回了一个包含真实用户数据的完整 JSON 响应。不是演示数据，也不是示例记录。

实打实的生产信息。

响应中包含了高度敏感的个人身份信息 (PII)，例如用户名、电话号码、地址、身份证号码、银行卡相关细节等等。

我盯着屏幕愣了一会儿。

这不仅仅是一次测试数据暴露，而是一个对象级授权 (IDOR) 漏洞，允许访问真实的用户记录。

如果端点易受 ID 篡改，那么下一个问题就显而易见了：

可以访问多少数据？

这时，漏洞的真实规模才开始浮现。

影响确认与意想不到的结局

至此，情况已经非常清楚：这不是一个只暴露无害演示数据的测试环境。API 返回的是真实的生产用户信息，而且没有执行适当的授权检查。

不过，在妄下结论前，我需要仔细确认其影响。

返回敏感数据的请求包含一个数字标识符参数。如果这确实是一个 IDOR 漏洞，那么修改该标识符应该能导致返回属于其他用户的记录。

为了验证这一点，我拦截了请求，并将其发送到 Burp Suite Intruder，配置了一个较小的标识符范围来测试 API 的行为。我没有进行大规模扫描，而是从 xxx00 到 xxx99 的有限范围开始，这足以观察端点是否存在漏洞。

很快，各种回应就暴露了问题。

每个请求都返回了不同用户的记录。

该 API 泄露了高度敏感的个人身份信息 (PII)，其中包括：

• 全名
• 电话号码
• 住址
• 身份证号码
• 银行卡相关详情
• 其他机密用户信息

该 API 没有设置任何授权检查机制。只要提供有效的标识符，API 就会直接返回相应用户的数据。这意味着攻击者可以自动化发起请求，获取海量的敏感用户信息。

换句话说，这不仅仅是一起小规模信息泄露，而是由对象级授权缺陷 (BOLA / IDOR) 导致的大规模 PII 泄露漏洞。

在这个漏洞赏金计划中，涉及大规模敏感用户数据泄露的漏洞通常属于 P1 级别，赏金最高可达 2 万美元。当然，我仔细记录了发现过程，收集了 PoC 请求和响应，并准备好了报告。

一切就绪后，我向项目方提交了漏洞报告。

有趣的是，大约四小时后，问题就被修复了。

起初，我以为快速响应意味着报告被优先处理，安全团队立即行动修复了漏洞。但后来收到项目组的回复，才发现情况略有不同。

根据他们的回复，内部安全团队已经通过其安全运营中心 (SOC) 监控系统，检测到了与该端点相关的异常活动，并在我提交报告前就开始了调查。现在看来，很可能是我在 Burp Intruder 测试期间产生的请求激增触发了警报，从而使他们的团队能够迅速识别并修复问题。由于他们审核我的报告时，修复已经部署，因此他们无法复现我报告中的问题。

因此，该报告被撤销，没有支付赏金。

所以，尽管该漏洞本身可能造成 20,000 美元的 P1 级问题，但最终奖励是 0 美元。

虽然听起来令人沮丧，但这次经历也凸显了漏洞赏金领域的一个重要现实：有时，即使你发现了一个关键漏洞并确认了其影响，但如果该问题在报告处理前已被内部识别或修复，你可能仍然无法获得赏金。

而这只是“游戏”的一部分。

经验教训

这次发现提醒我，一些最有趣的漏洞往往出现在你开始探索他人可能忽略的角落时。就此事而言，一切都始于侦察数据中一个不寻常的域名，以及挖掘旧数据时产生的一丝好奇心。扩大攻击面并相信你的直觉，常常能带来意想不到的发现。

这也凸显了网络安全研究员工作的一个重要现实：有时，即使你发现了一个严重的漏洞，也可能因为时机或内部检测而一无所获。虽然令人沮丧，但每一次这样的经历都会丰富你的学习过程，并帮助你改进未来的工作方法。

希望这次在云栈社区分享的案例，能给从事安全研究和渗透测试的朋友们带来一些启发。安全之路漫长，每一次探索，无论结果如何，都是宝贵的经验。