Some ways to find more IDOR

Hello friend!

你好,朋友!

I had learnt a lot of knowledges from others’ s blogs, write-ups, so I think I should give back to the community. 🙂 I hope this blog will be useful for someone.

我从别人的博客、文章中学到了很多知识,所以我认为我应该回馈社会。:)我希望这个博客对某些人有用。

This post is about some methodologies I had used to find IDOR vulnerability and some my findings relate to IDOR bugs.

这篇文章是关于我用来发现 IDOR 漏洞的一些方法,以及我的一些发现与 IDOR 漏洞有关。

  1. No ID, No Worry 

This is an bug that I had found in the past. It’s a site-wide IDOR allow me to read/modify/delete any information of other users, and yes, sure, I could takeover all accounts.

这是我过去发现的一个错误。它是一个站点范围的 IDOR,允许我读取/修改/删除其他用户的任何信息,是的,当然,我可以接管所有帐户。

After playing with functions of main website, I took a look back on my Burp History

玩过主网站的功能后,我回顾了我的Burp历史

Do you notice that? There is no parameter or URL path contains ID, but there is one thing causes my eyes. These API had a common pattern

你注意到了吗?没有参数或 URL 路径包含 ID,但有一件事导致我的眼睛。这些 API 有一个共同的模式

/something/something/self/something

These APIs return my information or doing some actions on behalf of me. I ask myself what if I replace that self word with my user ID ( user ID could be found on JWT token). For example, /ngprofile/aggregate/31337/fullProfile .

这些 api 返回我的信息或者代表我做一些动作。我问自己,如果用我的用户 ID 替换那个自我词(用户 ID 可以在 JWT 标记上找到)会怎样。例如,/ngprofile/aggregate/31337/fullProfile。

And BOOM! The response return my full profile information.

然后,BOOM! 回复会返回我的完整个人信息。

I tried to replace my user ID with other user ID ( the user ID is increment). So I could read other users’ s profile information.

我试图用其他用户 ID 替换我的用户 ID (用户 ID 是递增)。所以我可以阅读其他用户的个人资料信息。

I observed that all API contain self word is vulnerable to that IDOR, even the Change Email API.

我注意到所有包含 self word 的 API 都很容易受到 IDOR 的攻击,甚至连 Change Email API 也是如此。

So I could change email of any user. I could chain this bug with “Forgot password” function to send the reset passsword link of victim to my control emails and use that link to reset password of victim. So I could login to any account in the system.

所以我可以改变任何用户的电子邮件。我可以链接这个漏洞与“忘记密码”功能发送重置密码链接受害者到我的控制电子邮件和使用该链接重置密码的受害者。这样我就可以登录系统中的任何账户。

Key Takeaways

Try to understand applications ( how could this API/request authorize users, why there is no parameter, etc.), analyze carefully requests/responses. You could find more IDORs.

尝试理解应用程序(这个 API/请求如何授权用户,为什么没有参数等等) ,仔细分析请求/响应。你可以找到更多的身份证。

2. Don’t just replace ID

2. 不要只是替换 ID

When testing IDOR vulnerability, don’t just replace our own ID with others user/object ID. Sometimes one character could made a different.

在测试 IDOR 漏洞时,不要只是用其他用户/对象 ID 替换我们自己的 ID。有时候一个角色可以创造出不同的角色。

Scenario 1:

情景1:

The screenshot below shows when I replace my user ID with other user ID in API /accounts/0001176361, the server’s response “Invalid account number”

下面的屏幕截图显示了当我用 API/accounts/0001176361中的其他用户 ID 替换我的用户 ID 时,服务器的响应“ Invalid account number”

The screenshot below shows when I add “/” character append to this user ID, the server’s response return all information about this user. Maybe the “/” character breaks logic of the regex or pattern that server used to restrict access.

下面的屏幕截图显示,当我向这个用户 ID 添加“/”字符时,服务器的响应将返回关于这个用户的所有信息。也许“/”字符破坏了服务器用于限制访问的正则表达式或模式的逻辑。

Scenario 2:

情景2:

The screenshot below shows when I replace my application ID with other’s application ID (18385027) in API api/applications/18385027, the server’s response “access_denied” with HTTP code 401

下面的屏幕截图显示了当我在 API/applications/18385027中用他人的应用程序 ID (18385027)替换我的应用程序 ID 时,服务器的响应“ access _ denied”使用 HTTP 代码401

The screenshot below shows after fuzzing all character, I could bypass authorization control by appending %20, %09, %0b, %0c, %1c, %1d, %1e, %1f to application ID in this API. The server would return full information of that application.

下面的屏幕截图显示,在模糊所有字符之后,我可以通过在这个 API 中的应用程序 ID 中附加% 20,% 09,% 0b,% 0c,% 1c,% 1d,% 1e,% 1f 来绕过授权控制。服务器将返回该应用程序的全部信息。

Key Takeaways

(Old but gold): Don’t just replace IDs and wait for luck. Try to fuzz all possible character ( my list is %00 -> %ff) to break the logic of the regex or pattern that server used to restrict access. The more you fuzz, the more you luck.

(古老但是金子) : 不要只是更换身份证,等待运气。尝试模糊所有可能的字符(我的列表是% 00->% ff) ,以破坏服务器用于限制访问的正则表达式或模式的逻辑。你的毛越多,你的运气就越好。

3. Don’t Ignore IDOR in GraphQL applications.

3. 不要在 GraphQL 应用程序中忽略 IDOR。

A long time ago, I was very noob in testing GraphQL applications ( still the same now).

很久以前,我在测试 GraphQL 应用程序时非常菜(现在仍然是这样)。

When playing bug bounty in a private program, I observed this application using GraphQL. Immediately I remove all endpoints /graphql from scope =)).

在私有程序中播放 bug 赏金时,我使用 GraphQL 观察了这个应用程序。立即从 scope =)中删除所有端点/graphql)。

After playing with some functions, I gave a look at Burp History again and there is no request is found😐. So all APIs of this application used GraphQL.

在使用了一些函数之后,我再次查看了一下 Burp History,没有发现任何请求。所以这个应用程序的所有 api 都使用了 GraphQL。

I had wanted to know what does these requests look likes. So I add again this /graphql endpoints to my scope. 😶

我一直想知道这些请求看起来像什么。因此我再次将这个/graphql 端点添加到我的作用域中。

And luckily, I found 2 IDOR in that application ( just replace IDs).

幸运的是,我在那个应用程序中找到了2个 IDOR (只需替换 id)。

After that, I realize that there is a quite hard to implement security in GraphQL, even Facebook and Google have many bugs in GraphQL endpoints.

在那之后,我意识到要在 GraphQL 中实现安全是相当困难的,甚至 Facebook 和 Google 在 GraphQL 端点中也有很多 bug。

Key Takeaways

Don’t ignore anything. 😜

不要忽视任何事情。

I hope this blog can help someone find more IDOR vulnerability. This community help me so much so I want to give back my experience to community. 😄

我希望这个博客可以帮助人们找到更多的 IDOR 漏洞。这个社区对我帮助很大,所以我想把我的经验还给社区。

You can contact me via https://twitter.com/thaivd98 .

你可以通过 https://twitter.com/thaivd98联系我。

Thanks for reading! Happy Hacking!

感谢阅读! 黑客快乐!