【我是如何在一个电商平台上发现一个高危IDOR漏洞的】

# 深夜挖洞小记：一个“不合群”的请求如何撕开高严重性 IDOR 那是一个挖洞之夜，所有尝试都像石沉大海。我连续点了好几个小时，把各种请求塞进 Burp Suite，来回往 Repeater 里丢，结果全是空手而归。目标看起来干净得很，没有明显的攻击面，没有奇奇怪怪的功能，没有任何东西能让我觉得“就是这儿了”。说实话，我当时已经准备关掉 Burp 收工了。 然后我开始筛选带参数的请求。 有个接口引起了我的注意： ```http POST /api/v1/shopifyOrder/history

乍一看没什么特别的。就是另一个 API 请求而已。但再仔细一瞧，总觉得哪里不对劲。这个请求接收一个customerId，但整个请求里居然没有任何Authorization头。没有 Bearer token，没有 session 校验，就一个客户标识符躺在请求体里，仿佛应用程序完全信任发送请求的那个人。

这感觉……未授权。

请求体长这样：

{"customerId":"gid://shopify/Customer/9189799788709"}

凌晨两点的我：

“要是把这个 ID 改了会怎样？”

于是我注册了第二个账号，拿到它的客户标识符。然后替换掉原来的值，重新发送请求。

砰。

响应的数据里，直接返回了另一个用户的信息。

• 邮箱地址
• 姓名
• 订单记录

那一刻我以为自己搞错了什么。总会有那么一瞬间，你会觉得这个漏洞太明显了，明显到不像是真的。于是我又测了一次。结果一样。再测一次。还是同样的结果。

现在有意思的不只是 IDOR 本身。在进一步测试的过程中，我注意到这些标识符遵循的是可预测的递增模式，而不是随机的 UUID。我脑子里紧接着冒出下一个想法：

“能不能批量爬？”

于是我启动了 Burp Intruder。

• 一百次请求
• 两百次
• 三百次
• 四百多次请求

依然没有被封禁。
依然没有限流。
依然没有任何速率限制。

这个接口就像什么都没发生一样，一直在不停地返回数据。到这一步，问题已经从“有人能访问另一个客户的数据”升级成了“有人能以自动化方式大规模拉取数据”。

好像觉得还不够似的，错误处理也跑来添乱。触发畸形请求时，返回的堆栈信息里直接暴露了内部的服务器文件路径。单看这一点算不上什么严重问题，但绝对是那种让攻击者嘴角上扬的“附赠惊喜”。

最终的报告里包含：未授权接口、IDOR 概念验证、客户数据泄露、缺少限流机制，以及堆栈信息路径泄露。最终该漏洞被评定为CVSS 7.5（高风险）。

有意思的是，整个过程并没有什么花哨的利用手法。没有绕过链条，没有竞争条件，没有冷门框架漏洞。整个发现，仅仅是因为我在机械地翻 Burp 请求时，有一个请求看起来稍微有点“不合群”。

这大概是我最喜欢漏洞挖掘的一点：有时候，发现漏洞和空手而归之间的区别，真的就只是在合上电脑之前，多花了一分钟的好奇心。

原文链接：https://medium.com/@kanishkdadhich123/how-i-discovered-a-high-severity-idor-on-an-e-commerce-platform-f13a316aa71c