文章总结： 本文记录了一次导致全站数据泄露的严重IDOR漏洞。作者发现后端兼容哈希ID与连续数字ID，通过替换或移除参数，成功遍历用户数据并获取全库列表。文章建议勿被哈希表象迷惑，需关联注册细节并深挖边界条件以评估风险。 综合评分： 95 文章分类： WEB安全,实战经验,漏洞分析

【实战分享】抽丝剥茧：记一次导致全站用户信息泄露的严重 IDOR 漏洞挖掘

原创

Pwn1 Pwn1

漏洞集萃

2026年2月5日 08:47 山东

免责声明 本公众号所发布的文章内容仅供学习与交流使用，禁止用于任何非法用途。

1. 初步探测：功能点与异常

本次测试最早的切入点，其实是在目标站点的「账户设置」模块里。当时是在前期信息收集和功能点梳理都做完之后，我开始逐个去点一些和账户相关的操作。

在这个过程中，我尝试给账户添加一张 Visa 卡。这个流程本身没什么特别的，就是一个很常见的业务操作。不过在卡片添加完成之后，页面并没有直接结束，而是又跳出来了一个界面，用来创建所谓的「公司档案」。

这个创建公司档案的页面里，有两个选项，一个是「公开」，一个是「私有」。

当时我选择的是「私有」模式，然后正常点击提交。按理说，这里要么成功创建，要么给个错误提示就结束了。但实际上，在我提交之后，页面直接进入了一种 Loading 的状态，看起来就像是卡住了一样，前端 UI 一直转圈，没有任何进一步反馈。

一般来说，这种前端卡死的情况，要么是后端接口还在处理，要么就是后端返回了前端没法正常解析的数据。出于做安全测试的习惯，这种「不太正常但又没直接报错」的情况，基本都会让我下意识去看一眼请求和响应。

于是接下来，我就把注意力放到了网络流量上。

2. 流量分析：看似安全的哈希 ID

然后我打开了 Burp Suite，把刚才那个创建公司档案的请求完整抓了下来，并顺手发送到了 Repeater 里，准备反复重放看看具体情况。

在 Repeater 里查看服务器返回的数据的时候，我注意到响应里有一段 JSON 结构，里面包含了公司的一些详细信息。顺着 JSON 往下看，很快就能看到一个字段，是用来标识用户身份的 ID。

这个 ID 不是那种简单的数字，而是一串长度很长的字符串，大概 32 位左右，比如类似这样：

"user_id": "2ThB3jbnuh8ru5nNjnivYfjnwbfjin6HqR"

看到这里的时候，我的第一反应其实是：这大概率是个 Hash 值。而且从长度和字符分布来看，也确实不像是能随便猜出来的那种。

一般来说，如果后端只接受这种不可预测的长哈希作为索引，那攻击者确实很难通过枚举的方式去遍历别人的数据。所以在这个阶段，这个点从表面上看，反而给人一种「好像还挺安全」的感觉。

至少单从这个字段来看，并没有那种一眼就能利用的明显问题。

3. 逻辑突破：从 CSRF 到 ID 替换

不过既然已经抓到了接口，那肯定还是要顺手测一下接口本身的健壮性。

于是接下来，我先从一个比较基础的角度入手，尝试去修改请求里的 CSRF Token。我直接把原本的 Token 改成了一个随便写的 dummy 值，然后再把请求发出去。

结果是，服务器依然返回了正常的响应，没有任何校验失败的提示。

这其实说明了一件事：这个接口基本上是没有做有效 CSRF 校验的。不过说实话，这种问题本身比较常见，单独拿出来，通常也就算是一个低危或者中危点，还远远称不上什么严重漏洞。

真正的转折点，其实是在我思考「这个接口还能不能再往下挖点东西」的时候。

当时我突然回想起一件之前注意到的小细节：在注册账户的那个阶段，页面曾经短暂地显示过一个纯数字的用户 ID，比如像 18356 这种。

这个细节本身，在当时注册的时候并没有显得特别重要，但现在回头一想，就有点意思了。

那么问题就来了：后端在实际处理查询的时候，到底是只认现在看到的这个 32 位哈希 ID，还是说，它其实在底层同时兼容了数据库里原始的数字 ID？

带着这个疑问，我决定直接动手试一试。

我把刚才那个请求里的参数改了一下，把原本的哈希 ID，直接替换成注册时看到的那个数字 ID。

也就是：

原始请求参数：

id=2ThB3jbnuh8ru5nNjnivYfjnwbfjin6HqR

修改后的请求参数：

id=18356

改完之后，我把请求发了出去。

结果很快就出来了：服务器直接返回了 HTTP 200 OK，而且响应内容里，完整地展示了我自己的账户详情。

到这里，其实就已经可以基本确认了：后端逻辑并没有强制校验 ID 的格式，而是对数字 ID 和哈希 ID 都进行了处理。

4. 危害升级：可预测性与批量泄露

既然已经确认数字 ID 是可以正常使用的，那么接下来，一个非常自然的问题就是：这个数字 ID 有没有规律？

于是我又注册了一个新的测试账户，走了一遍完整的注册流程。注册完成之后，我留意了一下这个新账户对应的数字 ID，发现它变成了 18357。

这个结果，其实已经非常明确了：用户的数字 ID 是连续递增的。

那么接下来要做的事情就很简单了。

我直接尝试访问 id=18357，然后查看返回结果。果不其然，服务器成功返回了新注册账户的敏感信息。

到这个阶段，一个非常典型的 IDOR 漏洞，其实已经成立了：攻击者只需要不断遍历数字 ID，就可以访问任意用户的账户数据。

如果是在这里就直接写报告提交，按照常见的漏洞评级标准，这个问题一般会被定为「中危」或者「中高危」。但当时我还是觉得，这个接口可能不止这么简单，于是决定继续往下试一试。

5. 致命一击：全量数据泄露

在继续测试的过程中，我又注意到了一个相关的 API 端点：/UserId。

然后在这里，我做了一个相对大胆、但在逻辑上其实也算合理的尝试：我直接把 ID 参数整个移掉了，也就是不指定任何具体的用户 ID，直接请求这个端点。

说实话，在发送请求之前，我其实是预期它至少会返回一个报错，比如参数缺失之类的提示。

但实际结果完全出乎意料。

服务器不仅没有报错，反而直接返回了一整个列表，里面包含了数据库中所有用户的详细信息。

到这里，漏洞的性质就已经发生了根本性的变化。这已经不是简单的越权访问某一个用户的问题了，而是一个可以导致全站用户数据被一次性拖走的严重漏洞。

总结

在确认问题影响范围之后，我第一时间把完整的测试过程和复现证据整理好，并提交给了厂商的安全团队。

由于漏洞利用路径清晰，证据也非常完整，而且影响范围涉及全站用户隐私数据，这个报告在 24 小时内就被确认，并最终被定级为 Critical（严重）。

最后，结合这次测试经历，也简单总结几点给做安全研究的同学参考：

1. 不要被表象迷惑前端展示的 32 位哈希 ID，很多时候只是为了增加“看起来很安全”的感觉，后端为了兼容历史逻辑，往往仍然保留了对数字 ID 的支持。
2. 多关联上下文信息像注册阶段短暂出现的数字 ID，这种细节在当下看可能不起眼，但在后续测试中，很可能就是关键突破口。
3. 尽量深挖影响面发现漏洞之后，别急着提交，多花一点时间去试边界条件，比如能不能遍历、能不能批量获取、参数能不能省略，这些都会直接决定漏洞的最终价值。

原文https://medium.com/@Tanvir0x1/critical-idor-vulnerability-leads-to-user-information-disclosure-b0bb7f06aef5

觉得本文内容对您有启发或帮助？ 点个关注➕，获取更多深度分析与前沿资讯！

👉 往期精选

攻防演练中的“降维打击”：逃逸出内网边界的影子资产与SaaS供应链挖掘

【实战】利用 Salesforce ID 格式特性实现用户遍历

API 渗透实战：从 JSON 响应倒推隐藏的高危路由

一种利用 HTTP 重定向循环的新型 SSRF 技术

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：漏洞集萃 Pwn1 Pwn1《【实战分享】抽丝剥茧：记一次导致全站用户信息泄露的严重 IDOR 漏洞挖掘》