Some ways to find more IDOR

3 years ago 218

BOOK THIS SPACE FOR AD

ARTICLE AD

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.

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.

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

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

/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 .

And BOOM! The response return my full profile information.

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.

I observed that all API contain self word is vulnerable to that IDOR, even the 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.

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.

2. Don’t just replace ID

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

Scenario 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”

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.

Scenario 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

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.

(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.

3. Don’t Ignore IDOR in GraphQL applications.

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

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

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.

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

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