Webverselabs Clearance Challenge IDOR

Scenario :

CliniCore shipped a GraphQL API to power their new timeline feature. A viewerRole variable was added during development to allow the admin panel to preview how different roles see patient data. It was never removed from the production schema. A receptionist account with routine access to the system is all you need.

Solution :

Upon visitng the webapp , we find multiple endpoints to visit , the most important one here will be the API endpoint as ait will probably give us an idea on how the application works in details since other devs might wanna use these information to integrate this app APi to their project .

On the API endpoint we find these roles :

We will keep them in mind since if were to try and priviilege escalate later on we need to know the different roles that exist first . We also know the application uses GraphQL as mentionned in the API documentation . Now let’s create an account to be able to enumerate the application further .

As usual we will browse the webapp like a normal user , then check the Burp History for the different endpoints and request made to the server .

We do find these 3 endpoints , First the profile page , which is a GET request to the /api/me endpoint which only returns information about our user , no parameter we can abuse or modify to get other user’s information here .

Second endpoint is where we find information about all the users that exist , i tried all injections on the search parameter to see if we can list other users via SQLi but didn’t get anything out of it , apparently these are all the users that exist .

Now if we try to see information about a specific user , this is the GraphQL query that was made to the server , We see that it returns limited information due to the fact that we are only Receptionist .

If we check our profile we see that our user isn’t able to view some restricted clinical notes , maybe if we can escalate our privilege to one of the other roles we saw earlier we can get additional information .

We see in our request a field for ViewerRole , we see that for now we’re Receptionist , let’s try to modify this to one of the other roles we found eralier in the API documentation (admin,nurse,doctor,…) . I tried each role on all 3 patients , and good enough the doctor role could see additional information about the patients , The flag is in the user with ID 3 .

The application didnt apply any sort of RBAC or checks , which lead to this IDOR .

Other Checks :

Whenever we’re dealing with an application that is using GraphQL , the first thing we should try is the introspective query which is a built-in GraphQL request used to discover the API’s schema, revealing all available data types, fields, and operations., you can either use the GraphQL extension on Burp to generate this query :

it will automatically generate the restrospective query for us to use .

Once we do get a reponse , we can use a tool like GraphQL Voyager to turn this response into a graph that is easier to read , Just copy the response we got from the introspection query , and paste it in :

This should return a Graph which link each type and field to its corresponding relationship, visually mapping out the entire data schema and its dependencies , which opens the door for other vulnerabilities .

Something to keep in mind whenever we’re dealing with GraphQL .