声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。

国外一位白帽小哥分享了几种寻找更多IDOR漏洞的姿势，希望可以给各位有更多的启发。

什么是IDOR漏洞？

越权漏洞 IDOR 全称为 Insecure Direct Object Reference 不安全的直接对象参考

国内一般俗称“越权漏洞”，越权一般分为两种，“平行越权”与“垂直越权”。平行越权用通俗的话来讲，就是利用“平行越权”可以查看到同等权限账号的信息，如：张三和李四同为普通用户权限，张三利用“平行越权”漏洞，查看或修改了李四的信息；而垂直越权则是普通用户权限可以查看或修改更高权限账户（如管理员）的信息。

话不多说，来看看下面几种寻找更多IDOR漏洞的方法：

1、No ID, No Worry

白帽小哥之前在某个站点发现过IDOR漏洞，该漏洞允许攻击者读取/修改/删除其他用户的任何信息。在尝试完所有网站功能后，白帽小哥开始回顾他的Burpsuite的抓包信息。

不知各位是否有注意到，请求中没有任何参数，就连URL路径也没有包含任何用户ID信息，但是它们却有一个共同点：

/something/something/self/something

通过返回信息可以得知是由于执行一些操作，然后返回了当前账户的个人信息，于是不免猜想，假如将用户ID(用户ID可以通过JWT token找到)替换掉self会发生什么事情呢？例如：

/ngprofile/aggregate/31337/fullProfile

哦耶！响应包中成功返回了当前账户的完整信息。

白帽小哥如法炮制，将用当前用户ID替换为其他用户ID(用户ID是递增的)，，于是乎白帽小哥便可以读取其他任意用户的配置信息了。

同时他还注意到所有包含这个self的API都会受到IDOR漏洞的攻击，修改电子邮件的API也是如此。

这样就可以更改任何用户的电子邮件，可以利用“忘记密码”功能结合该漏洞，将受害者的重置密码链接发送到攻击者控制的邮箱中，从而使用链接重置受害者密码，这样便可以实现使用任意账户登录系统。

启发

尝试了解应用程序(API/Request如何授权用户，为什么没有参数等)，仔细分析请求/响应，也许可以找到更多的IDOR漏洞。

2. Don’t just replace ID

在挖掘IDOR漏洞时，不要只将我们自己的ID替换为其他用户ID，有时一个字符也可能会有意想不到的效果。

场景1：

下面的截图显示，当在api/Accounts/0001176361中将用户ID替换为其他用户ID时，服务器的响应是“Invalid Account Number”

而下面的截图显示，当在此用户ID后添加“/”字符时，服务器的响应将返回有关此用户的所有信息，猜测可能是“/”字符打破了服务器用来限制访问的正则表达式或模式逻辑。

场景2：

下面的截图显示，当在api/Applications/18385027中将应用程序ID替换为其他应用程序ID(18385027)时，服务器的响应“ACCESS_DENIED”，并响应HTTP 401。

而下面的截图显示，通过Fuzz所有字符后，可以通过利用%20、%09、%0b、%0c、%1c、%1d、%1e、%1f附加到此API中的应用程序ID来绕过授权控制，服务器将返回应用程序的完整信息。

启发

不要只是更换用户ID就想着挖到IDOR，可以尝试Fuzz所有可能的字符(白帽小哥的字典是%00->%ff)，以打破服务器用于限制访问的正则表达式或模式逻辑，你的Fuzz字典越丰富，你的运气就会越好。

3. Don’t Ignore IDOR in GraphQL applications

在一个私有项目中执行赏金任务时，白帽小哥观察到一个应用程序使用了GraphQL，于是他手动从scope中移除了所有/graphql站点

在使用了一些功能后，白帽小哥又开始回看Burpsuite的抓包历史，并未找到任何请求，因此，该应用程序的所有api应该都是使用GraphQL

白帽小哥想知道这些请求到底是怎样的，因此，他再次将这个/graphql站点添加回了scope。

很幸运，他在该应用程序中找到了2处IDOR(只需替换ID)。

在这之后，他意识到在GraphQL中实现安全是相当困难的，即使是Facebook和Google在GraphQL站点中也有很多漏洞。

启发

不要忽略任何东西！

最后，附上这位白帽小哥的推特：https://twitter.com/thaivd98

====正文结束====

原文始发于微信公众号（骨哥说事）：寻找更多IDOR漏洞的几种方法