GraphQL Top 10 Series: A1 — Broken Object-Level Authorization

3 years ago 190

BOOK THIS SPACE FOR AD

ARTICLE AD

Is it so hard to apply Access Controls rightly? Turns out to be true!

Broken Authorization!

I am sure you must have heard of those popular “Top 10” lists, that all the Big Boyz in the town talk about! Yeah, I am talking about OWASP Top 10 lists:

Web Application Security Top 10API Security Top 10Docker Top 10…

And one day I wondered, why don’t they have GraphQL Top 10? Isn’t that a bit different from normal APIs and fitting them into “API Security Top 10” would be an injustice to it!

So I looked around and didn’t found any blogs or videos talking about it! And that gave me some motivation to look into this and create a comprehensive list of Top 10 issues that happen with GraphQL-based APIs.

But ofcourse being an API, GraphQL APIs definitely inherit some weaknesses from the REST and other APIs. Those might show up in their own ways in GraphQL, but the issues stay.

So when I formulated the final list, it was kinda good to have some different issues listed there, which are different from API Security Top 10.

For 1, it proved my point of having another list for GraphQL and 2 — it helps me give something back to my infosec community! So why not :)

With this framework in place, anyone interested in pentesting GraphQL-based APIs can plan their pentests according to the most commonly found bugs and where they occur. And that’s my goal with this list!

And if you are interested to read about my journey on how I found these 10 vulnerability classes for GraphQL, check out my previous 2 posts:

They will help you get an idea on what I did to find out these issues — my approach on formulating a list of Top 10 issues with GraphQL-based APIs.

Here’s the list of issues:

GraphQL1: Broken Object-Level AuthorizationGraphQL2: Broken Field-Level AuthorizationGraphQL3: Broken AuthenticationGraphQL4: Lack of Resources and Rate LimitingGraphQL5: Broken Function-Level AuthorizationGraphQL6: Mass AssignmentGraphQL7: Security MisconfigurationGraphQL8: Cross Site Request ForgeryGraphQL9: Injection FlawsGraphQL10: Insufficient Logging and Monitoring

And our focus today would be on Broken Object-Level Authorization!

By far, the most common issue that’s been reported by many bug bounty hunters while pentesting GraphQL endpoints is Insecure Direct Object References (IDOR). And that attack just boils down to missing or misconfigured authorization checks on the objects being retrieved!

If the backend doesn’t places authorization checks on the retrieved objects, then an attacker can pull off the objects and information that they don’t have access to, using the GraphQL service!

That’s Broken Object-Level Authorization: Missing the Authorization checks at the object-level leading to access of restricted resources!

Which APIs Architectures are affected?

This vulnerability affects all types of API architectures including SOAP, REST and GraphQL.

Root Cause

Whenever an object identifier is used to access an object, this vulnerability can occur.

Common Occurrence

Getting user profile informationGetting private message sent by an app user, using the message idGetting the private repo’s commit history of a user using the git commit id

You get the idea right :)

Note: This doesn’t implies that Github/Gitlab/BitBucket or any other service for that matter is vulnerable to these attacks! (They might or might not be)

This vulnerability doesn’t only allows reading an object via object identifier but could also allow creation, updation or deletion of an object as well, if it occurs in GraphQL mutations!

All you need is a valid object identifier, and that could be brute-forced if it’s small enough!

Even if the object ID cannot be guessed, if there is some other vulnerability like SQL Injection or some info leak or a past breach, the object IDs could be recovered from those as well!

If this vulnerability allows write-access to the attacker then they can for example update the password of admin user and gain admin access or hijack account of other users as well!

Always check if the user is authorized to access the resource being requested.If you remember the API Security Maturity Model, then Level 3 security using the JWT tokens with claims can be used here. Thus, every user would be issued a JWT token with a scope and the claims, thus limiting their access to only the allowed resources.Audit the GraphQL API queries and mutations, especially those retrieving/updating sensitive data, to ensure that they authorize (that is, implement proper access controls for) users for every single request!Use random IDs that cannot be guessed (UUIDs). This is not considered a well-rounded protection, but just an added measure of security.

Broken Authorization maintains its position even for GraphQL APIs.

And the reason is pretty obvious:

Reference: https://graphql.org/learn/authorization/

The official documentation speaks for itself!

Since GraphQL doesn’t cares about adding Authorization, and its fair enough — it is a data query language for you, not an out-of-the-box API deployment magic tool!

So authorization is the headache of the developers. And if they mess up, the API is vulnerable to Broken Object Level Authorization issues.

Since OWASP API Security Top 10 list has Broken Object Level Authorization at top, GraphQL doesn’t lowers its priority either! We still regard this issue as the biggest issue in all kinds of APIs, not just limited to GraphQL!

I hope this post brought some enlightenment, and turned on a few light bulbs :)

Hopefully it was fun to read as well and made you enjoy learning about GraphQL pentesting!

I am planning to create a FREE course on GraphQL Pentesting and teach you everything on the subject! Also planning to build some accompanying labs to try everything hands-on :)

Interested? Let me know on in the comments below and feel free to connect on Twitter.

See ya!
Until next time, keep learning and happy hacking.

Read Entire Article