IDOR漏洞挖掘：如何通过JS文件发现隐藏API接口

导语：在漏洞挖掘过程中，直接尝试利用往往碰壁，但换个思路——分析JS文件里的隐藏接口——往往能打开新世界的大门。本文记录了一次在密码管理器应用中发现IDOR漏洞的完整过程：从最初的接口尝试失败，到通过JS文件发现新攻击面，最终实现越权查看他人设备信息。

一、背景介绍

目标应用是一款现代密码管理器，核心功能之一是添加可信设备。用户将某台设备添加为”可信设备”后，再次在该设备上登录时，可以跳过OTP验证码，直接登录。这个功能本意是方便用户，但实现上埋下了IDOR漏洞。

存在一个API接口用于获取当前账户的可信设备信息，该接口接收用户账户的UUID并返回设备信息。然而，这个API存在IDOR（不安全的直接对象引用）漏洞，允许攻击者查看同一租户内其他用户的可信设备信息。

IDOR是什么？

IDOR（Insecure Direct Object Reference，不安全的直接对象引用）是一种访问控制漏洞，发生在应用基于用户提供的输入直接访问对象时。任何形式的信息都以对象形式存储，例如用户信息就是通过特定标识符（如可预测的整数或随机字符串）来引用的对象。

当这些标识符可以被随意篡改，以未授权访问他人对象时，IDOR漏洞就产生了。

你可能想到的做法：创建两个账户，把账户B的UUID替换进接口地址，来获取账户B的可信设备信息。

/api/v3/trusted-devices/<UUID>

我也这样试了，但没有成功——接口返回了403权限错误。

说实话，一开始我已经打算放弃这个IDOR了。但后来在尝试执行另一个攻击的过程中，我开始审查JavaScript文件，想找出所有与admin相关的请求（以 /api/v3/admin/* 为路径的请求）。

就在这个过程中，我偶然发现了一个接口，让我眼前一亮。

这个接口是在点击”与你共享过密码的成员”时触发的，返回的是有限的账户信息，比如姓名和角色：

/api/v3/members/<UUID>/account/info

于是我想：如果 ../account/info 只返回有限的账户信息，那我改改路径呢？

没有太多复杂的操作，我只是把API接口路径改成了获取其他成员可信设备信息的格式——成功了。

/api/v3/members/<UUID>/trusted-devices/info

通过把另一个用户的UUID替换进这个接口，我成功获取到了对方的设备信息，包括：

至于UUID本身，在应用里到处都是泄露。例如：当一个注册用户与你共享一套凭证时，他的唯一UUID就暴露在分享链接里。

这次漏洞最大的影响是其他成员的外部IP地址和加密密钥泄露。

我最初报告时评级为”高危”，但被砍到了”中危”。不过，漏洞就是漏洞，能拿到报酬就行。

这次IDOR漏洞的挖掘经历说明了一个道理：直接尝试不成功，不代表没有漏洞。换个思路——分析JS文件里的隐藏接口、观察应用的请求路径——往往能发现新的攻击面。

关键技巧：

文章版权归作者所有，未经允许请勿转载。

THE END