# 深夜挖洞小记一个“不合群”的请求如何撕开高严重性 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