Md Injamul Haque retweetledi

DoS bugs in graphQL are fun!
When you run into a GQL (graph query language) instance when testing, check for DoS (denial of service) if it is in scope for the program. It is very common for developers to create a structure that can be queried recursively to cause resource exhaustion, be it CPU, memory, etc, leading to a denial of service for the either the entire graph endpoint or a subset of services/APIs that drive it.
What is graphQL?
Its basically an annoyingly structured query language built around JSON for calling APIs. Everything is explicit, case sensitive, and generally hates you. Hundreds of APIs can all be gated by a single graphQL instance, allowing developers to create queries or mutations that pull or update data points from multiple back end APIs in a single call. Most of the time the endpoint is "/graphql" or "gql"
How does this Denial of Service thing work?
I've found a bunch of these in my time in bug bounty. Its actually the first thing I check when I hit a graph endpoint. In its simplest form, lets say we have three different points of data: users, friends, and posts.
If we query the "users" object, we can request the friends of that user, and any posts the user has made. As we drill into the friends, we see it also lists the friends posts, and if we drill into posts, we see posts list the "user" object again so we can see who made it. What is the problem?
We can build a query that grabs users, and all its posts. Then for each user, all the friends, and all their posts. Then for each post for each friend, which user: pause here. Now we are back to users. So we nest it another layer deeper, for each user of each post of each friend, do it all over again.. and repeat, and repeat, and repeat. Then you run it once and the server dies. But don't actually do that.
The catastrophic nature of this type of query is multiplied by the data points you return, so if you find a single intensive/robust field and return it for each loop, that is enough to kill it. When testing this, start small (only one or two deep to gauge the server response time) so you don't hurt anything. If you are able to see that the response time is doubling or more, go ahead and stop and report it for safety.
The $8000 bounty was the best I've gotten for this particular bug, most companies aren't super keen to pay for denial of service bugs but they are real enough.
Here are a couple good explanations on this:
apollographql.com/blog/securing-…
graphql.org/learn/security…
#hacking #appsec #bugbountytips


English
























