The Dark Side of GraphQL

yeah so uh thank you everyone for joining in for my talk so my dog is the Dark Side of graphql and we'll be discussing that what is an attacker's perspective to graphql and how can you mitigate yourself from the security vulnerabilities so to introduce myself my name is parth Shukla and I am working for sequence security as a security analyst intern I have my own community in which I teach bounty hunting which is mostly related to web and uh I'm a reader bug Bounty Hunter and I script in bash in Python nevertheless my API Journey or graphql Journey started with the man himself Corey jabal who is right here and his book The hacking apis made a huge huge

impact in my life because that's how I got started with API security so what is graphql and why graphql is so important these days so graphql was created by Facebook and it's much much more efficient than the rest apis in rest API as you can see if we want to make a call to three different things you need three different calls to get the data where in graphql we just need one call to get all the data now this presentation like the time limit for this is just 25 minutes to have cut down this presentation to important points and this presentation would be a journey of how did I find a graphql vulnerability and I was awarded a four

digit bounty on that so it's all about the findings and what were the impact of that findings okay so the common graphql points these are the common graphql endpoints which you can find like graph iql is the web ID in which you can directly uh interact with the servers on your web browser whereas the endpoint you need to play around within Postman or bulb suit or any software which can help you to repeat the request with the payload you want so different type of queries in graphql unlike the rest queries with in which we have post get delete options head Trace Etc in graphql we have three major queries which are queries subscription and mutation

so queries are the general post or get request that we do like similar like get home page similarly in graphql we have queries and for rest all post put and delete that we have in rest uh we have mutations in graphql so every time you want to change data in your server there there has to be a mutation query if you are signing in if you are creating an account if you are placing an order if you are placing an order in cart everything has to go with the mutation query and this both played a major major role in the finding uh which I did and the Bounty which I was rewarded I will tell you the program

name as well because the vulnerability has been solved and it's been 90 days I founded vulnerability so actually more than 90 days okay so everything started with an introspection query what is an introspection query introspection query isn't the whole idea of your backend data like the query which you see here on the right side of the screen is the part of introspection query but when you run the introspection query by itself it reveals the sensitive data so you can see the bytes it's like it is like eight lakh 51 000 byte which is not feasible for human to get connection like what data is connected with what so for that we have something known as graphql Voyager which

will help you to get data like this this is pretty much simplified you can see what calls are being made you can see what calls are available you can see what data is connected to what node like what is the next data you can call like if you want to jump from the first box to last box how can you jump if the direct line is not there okay now in this we have the cycling thing as well like the rotation thing that first bar goes to third box and the third bar comes to again to first box this type of node this type of that this is the type of vulnerability as well so this is

known as cyclic or batching vulnerabilities I click call vulnerabilities which can help you to find dos attacks but dos is not the case that we are discussing here we are discussing account takeover which we are discussing uh manipulation response manipulation and stuff okay so okay with the help of introspection query which was the starting point of my finding I got to know that what calls are present uh at the back end of the data there are calls which are not meant to be public but you can find that in introspection query because it has to be there if server wants to call any of the function it has to be there in introspection query so it all started I was visiting this

website known as jumbo.com which is a supermarket in in Netherlands which is really big company so I was there launcher bug Bounty program and I was hunting on that and I got to find that they are on graphql so the first thing I did was the introspection query and to my surprise it was vulnerable to introspection query so normally introspection queries are disabled on a public facing servers they should not be allowed on the public pressing server so attacker does not have any idea on what is going on at the back end of the data so everything started with the introspection query and I you I was able to find out that okay if I want to call

customers address or pii details this is the path that I need to follow okay now I'm skipping this because this is not important for this uh presentation the next thing that I found was the batching vulnerability what is batching batching is actually a feature but attackers are using that to or expert the system so batching is like in one query in one query you can give multiple sub queries to return all the data so you might have come across the word known as rate limit okay what is the rate limit so rate limit is like you send continuous data continuous stream of data in X period of time and then you get blocked uh you might have no you might know the

status code 429 which is known as too many requests right we so if you are hunting if you are Bug Hunter if you are painters interested you have come across this scenario where you are getting blocked by the server to my surprise batching is one of the bypass to rate limit because only one request would have multiple queries and it will return you the multiple datas and batching can be done on both queries and mutations now just imagine that we'll be discussing this forward as well so you are given um a sign in page in which you just give out the email address and all you need is the OTP from the email address so

login flow is like sign up you'll get OTP and you need to enter the rotp and then you are logged in now in this case if there is a batching vulnerability and in mutation request how about if I can send 10 000 OTP and even one OTP is correct I'll get the correct response this is a normal scenario for account takeover so uh there is one more company in India which is known as upgrade Inc and they had this similar thing that they removed the password completely and they were like okay we'll just put out the email email will get a OTP and boom if you have the OTB you can log in similarly there was no rate limit

nothing I could Brute Force the OTP as many times I want so I'll give one to ten thousand if any one of the OTP is correct I'll log into the portal and I was able to even take over the CEO's account I could access the CEO account as well so this is like the flow of finding out vulnerability should be introspection then calling out the queries and batching normally people forget batching because they are like it's a feature and we can call that like it should be allowed to call multiple queries but it's not the case batching can be done for the Dos attack as well which is this is just an expert we're batching so

if anyone wants the slides you can just email me I'll send you the slide which has the POC and the attacks and everything so can you see the normal execution time it's 5 38 milliseconds just a normal query how can I know that if the response or a request or a web service vulnerable to batching or not so if I get multiple output inside of one response and the query so two queries two error responses then I can say okay it is vulnerable similarly I'll just keep pasting out everything and see the execution time more the queries the more resources I am using of the web server and the execution time increases so imagine if you don't have the rate limit

and you have the batching vulnerability so 10 000 requests each taking around 5000 milliseconds and those 10 000 requests are getting repeated for n number of times so I guess your server is typically dead by now so this uh batching can be stopped by using the depth query limit that you should not allow more than five to six query inside a request similarly authentication bypass can be done using batching the weight is done is I discussed bypassing OTP the main reason you can bypass ODB is the variable function you can put out multiple variables inside one query in which you can see now there are three inputs so I'm giving three otps and this is just an example you can give thousand

otps as well it's not an issue if batching is a vulnerability so once you send the mutation request to the server and if there is a batching vulnerability you will get to know that what OTP is correct and if you can log in or not okay next thing comes is testing for directive overloading so directive overloading are pretty new directive overloading is something that people forget just because they are concentrating on batching so what are directives directives is something you all know like it's for Loop if Loop but in the case of graphql it's like there are two main directives you can create your own directive as well in graphql but two major directives are Skip and

include so skip is like skip if the condition is true then it will skip the data and Skip if the condition is true it will include the data Okay so uh in deductive overloading and deductives are typically prefixed by at the rate so if there is you know that okay this is a directive okay so uh in this POC uh we can find out that okay if it is one able to deductive overloading or not so this is not the actual POC this is actually a POC by my company which they gave me a sequence security whom I do internship for and uh I gave them the Target and they find out okay there is a

vulnerability okay so this is a normal transaction you can see the execution time is 4 112 milliseconds and yeah there is one more live incident I'll tell you after this and you can see the normal attack instance it will take 2000 milliseconds because I'm I'm calling the directives like thousand detectives in one request which is taking all the resources okay now Best Buy Best Buy is the biggest electronic seller in us right we all agree to that and Best Buy uses graphql which I reported around two weeks or three weeks back and now they are secure because they kept a authentication so I'm allowed to take their name there is no disclosure violation here but they

had the open or graphql portal in which I could make the authenticated request all I need was to play around with jwd token so if I know how to play around with jwd token which is fairly easy on their implementation it was not that complex but I I could make all the authentication requests speaking of authentication what happened with the jumbo case was when I find out that found out that the introspection query leaked all the calls there were mutation calls enabled as well which were not required any authentication so I would I was able to change the price of the items on their website so if I want to buy a milk or a

bread instead of 10 I would do 0.1 dollars and then I'll buy and then I'll change back the price again to ten dollars so they don't know what really happened so again if you think this this like uh this could lead me to more than five digit Bounty but they had some security budget which was restricting them to pay and we can see why the budget was restricted they didn't have the proper security but uh nevertheless so with the help of introspection you can do a lot of things like trust me if you can know that what calls are being made and how to call data you can play around graphql a lot and uh

I love graphql because it's pretty new um companies are moving to graphql like Best Buy was not graphq or not on graphql before but now they are moving um and there are bunch of other companies which you can find on graphql like Best Buy jumbo and everyone so yeah I would I want to take more companies name but I'm not sure if they are secure or not so I'm I'm restricting that um yeah so these are the possible mitigations that you might want to do now graphql is an API security issue but it doesn't mean that they don't have the injection issues the normal injection issues like combined injection SQL injections excesses are still present

out there in graphql uh I don't have POC for that because I didn't found any until now I am looking for injection attacks like every day but I'm not getting it I'm not sure why uh but rate limit rate limit is a major thing that you would like to do and the implementation of depth limiting for incoming graphql queries that is the queries that you are sending to server yes so this are the possible mitigations this presentation was supposed to be like 50 or one minute or 50 minutes long but I had to cut down on all the pocs that I had because if I discuss one POC that would take me around or 10 to 15

minutes because but I had what with peace ads and everyone but there was a time restriction so I couldn't really show you the POC but you can always hunt out for graphql vulnerabilities turn on your top suit intercept the request go to login flows and if there is a graphql thing you will eventually find that slash V1 slash graphql or anything like there are so many like Apollo graphql is so famous so just go on a polar graphql go on the customer list and try to hunt on those vulnerabilities if I am like I don't remember but even Airbnb is on graphql so these are some common targets that we pick up as a bug Bounty Hunter and

try to hunt on those these are simple vulnerabilities that you can find there is nothing like brainstorming out here once you have the introspection you know what queries to call and how to call and what vulnerabilities to find so yeah so sorry I had to cut down on the POC part I I like for the purpose of presentation on my earlier seminars I did take the explicit permission from Jumbo to show all the datas because now they have changed all the implementation but due to the timing issue I am not able to show it here so so sorry for that but feel free to reach me out for the original PPT and I can send you that with all the aposes and

everything so thank you so much for joining in I hope this was a productive session and I'm sorry this was a fast one thank you so much guys [Applause]