官网：http://securitytech.cc/
我是如何发现一个无需认证的敏感信息金矿的
作为一名漏洞猎人，我学到一个经验：最简单的接口有时可能隐藏着最大的错误。一次 API 请求。一个未受保护的参数。仅此而已，就能把一个安静的网页变成敏感数据的金矿。
在最近的一次漏洞猎寻过程中，我偶然发现了一个几乎完全开放的接口。没有登录提示，没有令牌，没有访问控制。只是一个孤立的端点，悄悄地向任何礼貌请求的人提供用户数据。
一开始的例行侦察很快演变成了严重的信息泄露漏洞，泄露了完整用户资料，包括电子邮件、电话号码和管理员标记，全部无需认证即可获取。
以下是事情的经过。
1. 侦察
像我大多数的漏洞猎寻会话一样，这次也从一些例行侦察开始。我启动了 Subfinder，让它自动运行。现在这已经成为一个固定流程。
结果出来后，我关注返回 200 OK 的子域名。我通常先从这些域名开始，而不是先看重定向或其他不常见的状态码。
其中一个域名向我展示了登录提示。一开始看起来很正常，但我决定深入挖掘。我对主机进行目录和文件扫描，发现了一些返回 200 OK 的端点。这时事情开始变得有趣。
访问其中一个端点，起初没有显示什么内容，但它似乎在后台创建了一个匿名会话。突然，我可以在不登录的情况下浏览应用的部分功能。有页面可以创建工单、查看用户资料及其他内部功能。虽然字段大多为空或缺失，但仅仅是能够在未认证情况下看到这些界面，就立刻引起了我的注意。
2. 探索
通过匿名会话访问应用部分功能后，我开始深入探索。我点击了所有能找到的按钮、标签和链接。目标是尽可能全面地映射攻击面。即使页面为空，它们的存在也可能暴露隐藏的功能或配置错误。
不久就有发现。在界面中，我找到了创建新工单的功能。看似正常。但吸引我注意的是一个额外选项：一个按钮，标签类似“Include Users（包含用户）”。
出于好奇，我点击了它。
请求发出，页面加载。然而和应用其他部分一样，响应是空的。没有用户，没有错误，只是一片沉默。一开始似乎是死胡同：也许该功能受限，或者匿名会话不允许访问用户数据。
但空响应并不总是故事的结尾。有时，它们只是隐藏着等待被发现的东西。
3. 利用
在 Burp Suite 中观察网络流量时，有一个请求引起了我的注意。它是在我点击 Include Users 按钮时触发的，请求大致如下：
GET /tasks/task?handler=Users&factoryId=0 HTTP/1.1
Host: localhost:3000
handler=Users 参数立即引起警觉。即使响应为空，也很明显应用尝试获取用户数据。只不过因为匿名会话限制，范围被限定在 factoryId=0。
这引起了我的兴趣。
我开始手动修改 factoryId 参数，并通过 Burp 重放请求。为了简化操作，我按响应长度过滤，寻找不同于通常空响应的内容。不久，一个响应明显更大。
打开后显示完整的用户记录：
注意： 此处展示的漏洞请求与响应是在本地测试环境中复现的，该环境行为与实际目标类似。敏感细节和原始目标 URL 已被删除。
姓名、电子邮件、电话号码、职位、管理员标记等。只需修改请求参数中的数字，就能让未经认证的用户获取所有这些信息。
到此，我清楚地知道自己发现了什么。
4. 负责任的披露
一旦确认漏洞影响，我立刻通过正确的披露渠道报告。三方团队迅速、专业地响应，几个小时内确认了问题。
让我印象深刻的是他们的行动速度。漏洞在两天内就被确认、修补并彻底解决。端点被加固，访问控制得到正确实施，防止进一步未经授权访问用户数据。
看到报告得到快速而有效的响应总是令人欣慰，这是披露得当如何提高应用安全性的典型例子。
每个漏洞都有它的故事。这个漏洞始于一个简单按钮，却最终暴露了严重漏洞。这提醒我们，有时只需一点好奇心，就能发现更大的秘密。
