API接口上的IDOR漏洞

  当我在请求某一API接口时。发现缺少访问控制策略(已损坏的访问控制
策略),这导致我可以未经用户的允许,编辑或删除他们的工作经验和教育细节

先决条件

什么时IDOR?
不安全的直接对象引用(Insecure direct object references,IDOR)是一类访问控制漏洞,当应用程序使用用户提供的输入直接访问对象时,就会出现该问题。

最近3天我都在测试一个目标站点,发现了一些xss和突破速率限制(Rate limiting)漏洞。我已不再满足于这些漏洞,所以我开始进一步的挖掘。经过一小时的查找,我的目光停留在一API请求的响应上:

可以明显的看到这段响应包含了一个‘id’参数(“id”:2150),这引起了我的注意。
该响应产生的缘由是我在目标站点的个人资料中添加了工作经历,最初的请求为:

我立刻对该位置进行fuzz。我尝试在请求包的JSON中添加一些参数来创建另一用户的工作经验,然而什么也没发生。
当我准备放弃时,突然想起检测一下工作经验的删除功能。于是我删除工作经验并抓取请求:

你应该也在这URL上发现了那个有趣的参数,删除的URL为:https://www.target.com/api/user-firm/2150
数字2150再次引起了我的主意,我们再看看该请求的响应:

响应的状态码为204 No Content,意味着工作经验被成功删除并且这位置上已经没有内容了

现在我按照上面的步骤创建了另一个用户并且添加工作经验,该请求为:

响应中的一些字段唤醒了我之前的想法

这里"id"=2151,是我之前账户创建工作经验id的下一位数字,这使我知道id是有规律变化的
我立马在第一个账户中创建一个新的工作经验,现在的想法是验证IDOR漏洞
我尝试使用第一个账户通过修改请求包来删除第二个账户的工作经验
第一个账户的删除请求:

将2150改成2151,并发送请求:

成功!
之后我使用同样的方法尝试添加教育细节,幸运的是我再次成功了

提示

  • 必须使用参数查看API接口的响应
  • 如果API中传递了一些数字,那么您必须尝试使接口fuzz并寻找IDOR。

谢谢您到目前为止的阅读。 希望你学到了一些东西。

原文地址

https://medium.com/@abhiunix/idor-on-api-endpoints-e08c740e87a2

原文地址:https://www.cnblogs.com/g0udan/p/12685253.html