IDOR Vulnerability

IDOR - Background Info ;

Website.com/view_user_info?user_id=1

In its simplest and most common form, an IDOR vulnerability arises when the only input required to access or replace content is from the user.

What are IDORs?

This is a good place to start An IDOR is a vulnerability which occurs if the code doesn't check if the user has permission before allowing access to something

There are 3 different vulnerabilities which are called IDORS ;

BOLA Broken Object Level Authorization

BODA - Broken Function Level

Authorization

Lack of authentication

The three types of IDOR :

1:) Unauthenticated ;

Lack of/missing authentication

You can access a resource without being logged in .

2:) Authenticated

Broken object level authorization

You can access a resource, while being logged in but where the resource belongs to another user

3:) Permission

• Broken function level authorization

You can access a resource, while logged in but where the resource requires greater level of access than you have .

In our first example, whats stopping someone from checking another users ID and getting all their information ?

Website.com/view_user_info/user_id=2

Get other user details

This code example demonstrates how this can occur.

<?php

$user_id = $_GET['uid']; $user_info get_user_info($user_id);

The server is taking in the users id and directly displaying that

information.

To fix this the server shouldn't believe the user, but rather extract the session ID and check on the backend.

<?php

$_SESSION['uid'];

$user_id= $user_info get_user_info($user_id);

In case of Serverless checks, the application must have a mechanism to check a signature (JWT)

Serverless

Cookie + Signature =Tamper proof

Forced Browsing

Similar to IDOR, forced browsing can occur if the application exposes a direct reference to a file location.

Here an attacker can visit the link and retrieve the image even though it is a private image

UUID - Safe? Think not...

bda76035-ffd3-4e0c-95d6-65eccbf336fb

Here it is encoded in (uuid v4) Universally Unique Identitier.

Consider the server accepts arbitrary uuid's from the user, yet the uuid is too long and random to guess. What can an attacker perform?

A UUID can foil your plans and make it really hard to exploit this hypothetical IDOR scenario. So when you come across one try to create a few users in order to get their UUID so you can try to understand how the UUID is formed. If there is no specific pattern then only thing to do is to enumerate the UUID. Sometimes there faults in the API that can leak the UUID, sometimes CORS misconfiguration can leak it too, so you need to try and find a way to enumerate the UUID and perform IDOR.

One option is to try and find a location the UUID gets leaked.

if you face an encoded value, you can test the IDOR vulnerability with decoding the encoded value. if you face a hashed value, you should test whether the hash value is an accessible or predictable value.

Bypassing Validation

How To Think ;

1. Understand the business logic of the application Don't be on auto pilot and don't change random IDs in API calls until you see Pll in the response. There are automatic tools that can do this for you. Think.

2. Every time you see a new API endpoint that receives an object ID from the client, ask yourself the following questions:

• Does the ID belong to a private resource? For example, if we talk

about some "news" feature, and the API endpoint is

"/api/articles/555", there's a good chance that all the objects

should be public by design, since articles are public. • What are the IDS that belong to me?

3. Understand relationships between resources Understand that there's a relationship between "trips" and "receipts" and that each trip belongs to a specific user.

4. Understand the roles and groups in the API Try to understand what the different possible roles in the API are. For example-user, driver,

supervisor, manager.

5. Leverage the predictable nature of REST APIs to find more endpoints ,You saw some endpoint that exposes a resource in a RESTy way? For example: GET /api/chats//message/

Don't be shy, try to replace GET with another HTTP method.

If you receive an error, try to:

• Add a "Content-length" HTTP header

• Change the "Content-type"

How To Test:

The basic way to test for BOLA is to guess the random ID of the object, but this doesn't always work. The more efficient way would be to perform "Session Label Swapping":

1. Identify the session label:

A session label is a generic term to describe every string that is used by the API to identify the logged in user. The reason I call it a session label and not a session ID or authentication token is because, for BOLA exploitation, it doesn't matter!

2. Log two session labels from different users:

Create two different users and document their session label.

Tips & Tricks:

Object IDs in URLs tend to be less vulnerable. Try to put more effort on IDs in HTTP headers / bodies.

UUID instead of numeric values? Don’t give up!

Use the “session label swapping” technique or find endpoints that return IDs of objects that belong to other users.

Always try numeric IDs. If you found that an endpoint receives a non-numeric object ID, like a GUID or an email address, give it a shot and try to replace it with a numeric value (e.g.: replace “inon@traceable.ai“ with the number “100”)

Received 403/401 once? Don’t give up!

It’s not extremely common, but some weird authorization mechanisms only work partially. Try many different IDs. For example: if the endpoint “/api/v1/trips/666” returned 403, run a script to enumerate 50 random IDs from 0001 to 9999.

Find the most niche features in the application

Let’s say you found a weird feature to create a customized picture to your profile only during avocado awareness month (it’s June btw), and it performs an API call to

/api/avocado_awarness_month/profile_pics/<avocado_emoji_id>

There’s a very good chance that the developers haven’t thought about authorization there.