Attacking GraphQL: A guide for penetration testers - Keith Makan

okay hi everyone um welcome to track one this is uh tacking graphql my name is Keith McAn um and I am I'll do the who Who's Who Am I slide in a second but this is my I think my third or fourth bsides talk I love contributing to community and I'm happy that everyone came to listen to this so hopefully everyone learned something um so yeah who am I my name is Keith McAn I've been in cyber security for about 10 10 to 12 years I sort of won't be uh don't don't take my word for that like around that figure um I'm a technical author I've written two books um one about Android uh Android secury assessment and one

about Automation and uh i' this year I did three really difficult things I founded a company with some uh folks uh I know from Europe I completed my Master's thesis uh that's the title and I fed my first boxing match yay so that's uh that's me um about someone's about to blow my brains out sorry knock my brains out um and yeah it might be a strange leap computers to fighting but I think if you can like get everyone to look at you and expect you to say something smart it's you'll find it's easier to get someone to punch you in the face um so that's my journey with that and in that light like I've themed all of the

all of the images you see are like me generating stuff through Google Gemini um and uh it's like there's been there's been no annoying graphic designers involved in any of this um I'm just joking obviously but it's themed around boxing it themed around like my nickname which was Mr Robot I chose that cuz it's just closest thing to hacking that seemed Fighter um anyway so let's get into it gra Beginnings so this talk before I get into it is about graphql there there's no intro slide to the old topic I just remembered but um yeah graph I've been testing web security for around about the 10 years you see there um I've faced a lot sort of run into a

lot of different Technologies and um recently I think the growth in gra were pretty interesting lots of different organizations have been adopting it and um at typical pentest I keep running into this Tech and I find there's very little open talks and people discussing how to attack it just from my corner of the internet I guess so I thought it would be a good idea to give bsides a a nice proper talk about graphql and what you should expect and how you actually what are the gra graphql specific testing stuff you should look out for so that's just wheel um sorry I skipped the slide there um how it started out well gr's a Facebook idea um they were facing

what apparently with some limitations around how race apis work um the typical stuff was I mean it's not really there's nothing wrong with rest API I think we've just done them to death and people are looking for something more flexible um and we'll get into exactly what was wrong with the some of the things some of the limitations around rest and why it came to be but the basic story gra was uh you know less about just about 10 years ago it was start we started developing it 2015 they released it and in 2018 2019 is when they established the graph um Linux Foundation under the Linux foundation and uh it's obviously like an event that shows how much public

Community is sort of grown around the around the the tool and there's no real 2024 point it just makes the slide look a little bit more rounded to say it's continued and it's been good um so yeah adoption this is the their stack page for graphql very quick reference um very big names uh that make a lot of money they bued a lot of important important stuff and they've been adopting graph girl quite aggressively um we'll look at why in a second WRA also another cool piece of art um uh yeah WRA well firstly the we'll see in a second how the query format works but it allows flexible utenation and you know sum summarization

of of queries without changing a profound amount uh about the back end so you can you can slap things onto queries and take them on and the same front end will will handle everything um there's also a very flexible quick query language so um you can ask for a lot you can ask for a little what whatever you need kind of the same point as the previous one but um the other thing is really good is a strong strong typing data typing right from the beginning um graphql requires you to declare which types uh go into your typing you actually design a typing system for graphql and the runtime handles how that ends up in in resolving into actual web

traffic and queries so back end so um the good thing about that that query language which is a bit complex to get your head around at first is it bakes in the types so there's no um stuff like PHP where you can pass a string off and get it to be treated as an INT or the other way around it expects you to to if you give it a string it'll be treated like a string if you give it an INT um it'll follow right through depending on how you implement it on the back end but the runtime keeps it pretty strict um and then also rapid API Evolution because you have one end point

um that's representing a lot of a lot of possible transaction you can scale your back end and the front end can stay the same you can rapidly change what's going on behind the endpoint um and the query language and the implementation The Roots don't need to change a profound amount and then also because it's Facebook um you've got a lot of developer mind share they've got communities around building the product so there'll be a lot of support and a lot of exciting stuff happen happening um so yeah let's get into the anatomy of a graph girl I'm really proud of this one by the way lots of detail um exactly what I wanted nice I you could make a

whole game with this with this Tech um I say that because like uh growing up there was all these RPG game makers I'm sure you guys know that and the most annoying part was like getting Sprites that you actually wanted so now that problem solved I'm going to be making games for the rest of my life um so yeah anomy of GRA also the icons llms as well very consistent Metal Slug X that's the key word um so yeah typical setup of a graph um uh application is you have the client side and the server side and depending on which uh approach you take your middle we might be party view graphc server it might be something you slap on

or work around it and then the other moving parts to this conversation are the resolver is the logic and the storage the the logic and the storage um are the pluggable parts so you can have post gray SQL a bunch of other storages that you you work in and the logic is the stuff um that uh once once you've decided what you to ask for how do you get that back to the to the to the middle way basically um so that's where you write like give them a hello world page uh look up their IDs or whatever and the resolver part is what takes your type system and splits it into into resolvable logic um so yeah uh the one

thing you need to get your head around with graphql is the schema and I've the stuff I've written in bold um is the the basic requirement for a schema it just needs a query that's the root type and the other Stu you can add on there's queries there's subscription types and mutation types and you can think of queries as get me stuff even though that's not like you don't it doesn't have to only be retrieval you can do mutation with queries if you really want but the idea is that mutations are kind of like your post uh requests that send um payloads and change stuff and the queries are retrieval they they take payloads but they don't modify State

that's the guidance and just an example I've expanded the um the type query here to some cve specific stuff so for an example you could have queries that are like get cve title get score and for example a mutation would be put cve RI like if you want to add a link to cve supposedly and um I didn't flesh this out a lot but it's got uh it has basic types obviously like any other typing system so it has strings ins floats IDs and booleans there's also enums um and lists which I didn't mention here a little bit more complex than a basic type but um you can use these to build more complex typ so if you wanted to

make a cve ref for instance you'd use a string to represent the URL maybe an INT amount of counts or hits or whatever is you can be very creative with with a type system it's fully expressible people have been building lots of complex and cool stuff with it um and a simple query exchange looks like this you have all your post headers this is taken straight from like uh you know there's lots of playgrounds online where you can where you can try stuff uh people are hosting this just so you can test out the technology um so this is typical HTTP stuff um the only weird thing about this is the Json at the bottom and it holds your query this

isn't the cleanest query by the way it's a it's a introspection query it's a little complex I'm not going to totally unpack it but the basic thing is you have a query uh sort of Json is object in the in the array I keep showing with my hands but you know looking at my hands so um there's a there's a there's a query type and inside that a questions you want to ask so if I had to walk through this this query it' be hey give me information about a type the name is asset and what I want to know about this type is the the name um and uh uh the field so for each field I'd like the

name the description and the type of the field and that's the way the conversation works every time you want to add to the conversation you Nest another question or you slap it onto a list that's how that's how it works and this is where you get the whole idea of um precise fetching there's no under or over fetching you ask for what you get and you get exactly that versus a obviously versus a rest um Endo where you ask for a thing you get it you get only those things back there there's no VAR ility you have to cash everything you get whether you need it cashed or not um so yeah a little more flexible

and then some of the I think the big uh things that I as a non- everyday gr developer noticed is is one of the more common um offerings is things like Apollo no. JS has Express graph G which used to be Express Express graph G on its own it's now not maintained on its own I believe it's part of some npn package then there's um hura and post graph file I if I'm saying that right but um yeah post graph file allows you to let me try to adjust this post graph file allows you to generate um graphical API straight from postgrad SQL databases and this is a brilliant idea because a lot of people uh obviously dredge around

the whole concept of generating a schema to use this thing it's like why do we have to learn this new language so if you can speak poql you can you can migrate to Graal pretty easily using this Tech um and then why would you use each one this is just a Spiel I think all of them are probably great I wouldn't I'm not here to um argue about sort of these Minas but Apollo is great because it's it's big it's branded it's well supported it's got a large community and tons of documentation you basically can't get it wrong no JS lots of other things the great thing about graph's no. JS no. js's graph is that it

uses the same HTTP engine as no. JS obviously and that a lot of people love that um hura does some AI stuff not an expert on hura and I mentioned why graph post graph was cool so uh let's look at some attack patterns o very interesting thing that's wrong with this um you guys will notice that the reflection doesn't work so llms are great at uh at making pictures but reflecting is is not that right one would say that that's almost more authentic or intelligence given what's going on today um we're good at describing things but not good at reflecting on him um so uh yeah Graal specific attack patterns um but so the first slide is just you get all the

basic stuff like this is at the end of the day just a delivery mechanism U all the poison can still be inside it doesn't change that so you can still have SQ you can still have SQL um xart xss all the good stuff csrf I'll talk about CSF specifically because there's uh the nature of the trans transaction mechanism means that there's only certain ways that this is going to be possible due to the way people commonly defend against csrf um but we also talk about the the last four which is very specific to graphql introspection disclosure batching and nesting overloading aases and circular queries I'm not going to spoil the party too much but um yeah let's talk about CS RF

uh firstly if you want to see if there CS RF on a graphql thing the one the Nate the reality of it is that uh you're going to be exchanging Json objects the whole time and the only time it's possible to csrf first of all do I need to explain what csrf is yes no I'll just go over it real quick cross-site request for um One browser origin is allowed to send uh uh requests to another browser origin on behalf of the user not always with their consent or awareness uh so that's crosslite request fory the way that we prevent this in graphql is usually um by making sure that the server doesn't accept anything except application

adjacent content types and the reason for that is because if you allow other content types you can contrive a form submission that will uh sort of uh have enough stru in it to to to to be uh interpreter as Json while not actually being full Json so there's too many too much um variability around the Json subtype uh to if so that if it's not strict you can probably do CSR very very easily um and uh if you can't do uh if you if you are accepting so I didn't label the stuff but the top one is no and the bottom one is yes so top is no we don't have CS we don't have content

type freeness so we then after r on cause so like you have to hope that the same origin policy is relaxed in some way that it allows you to send a request on behalf of the user that this is the top route the bottom route is yes you can do um application uh you can submit data types other than application Json and that just means like you look for a form to redirect to inject uh you try to fire off the request and Bobs your uncle so pretty simple there the other thing that's unique so the first thing we're talk about that's unique to grael um is something called introspect and this is like a a sort of self-documenting um

function that apis have it's basically a special question you ask an endpoint and it returns a description of the schema that it used to format data um and you know it's a little bit uh this is a bug that tends to be a little bit flaky to report uh depending on the context it's heavily contextualized bug because many people when they report this stuff it's uh intentional the documentation is intentional it's usually built in and it's okay to discover schema but there are times when um you know this is just left on and you're sort of slapping in a lot of functionality and you forget that people can look up your schema and you might include things in there that's not

uh it's not not too great to to publish two examples I found is cve 2024 6861 and this is um they literally had authentication keys in the in the schema that was being disclosed I don't know how that that happened really but um it's great that there's a documented example where this goes wrong so developing don't argue with me that much um so yeah those are two examples and this is what an introspection query looked like I kind of leaked it the other uh in the previous slide you basically have these uh special queries um key wooded queries that start with underscore stuff I'm not going to become I'm not going to be too technical about

about this just yet but the underscore underscore name means it's an introspection query it returns documentation about a type and inside that field you can say uh from the schema I want the query type um maybe I want the mutation types and of those I want the names the fields and you're just discovering more and more of the more and more of the of the the the graph basically um and this is what the return looks like it'll return a sort of Json object of of schema typ quy and NS and then um this is a sort of more full example I guess so um here you have introspection query that was added by the by the playground itself so it's

going to it's going to have like casing that's not uh not 100% uh consistent with burp stuff that's why it looks a bit different um and you can see it returning um the query it says hey there's a query type there's a mutation type and here the here are the the the types that are embedded there they have something called aggregate there's also a description field which you shouldn't forget about because it might have very verbose information of what's going on but that's that's the basic thing um the other interesting keywords to try to do interection with is obviously type type name type name kind name field name I always burp the most when I have to give

talks sorry um and the rest of the cool stuff and this is uh for burp I believe they just added this which is really cool um you can right click and just say set an introspection query and it dumps a whole introspection query straight into your into your into your post request Bob's your uncle you can you can get that done the other the other way to do to exploit introspection um is to use inq which is a a burp extension you can install very easily um and basically you just send this to nql and then it'll dump the whole schema um and one of these files uh I don't know if there's a mouse so at the bottom of these files

there's a thing called schema. Json it holds the whole schema Once you pull that out um you can take that over to something called graphql Voyager which um is like it basically just takes your the result of your introspection query and it produces a a cool graph that looks like that um and you know this is the worst way possible to document a graph but uh forgive the technology this is the place where it is um but uh assumedly you'd have small enough schemas that this would be useful to you in some way the point of this is that you can look at it and figure out whether there's circular dependencies whether there's things that are

unnecessary redundant um things you don't know connections you don't know it's a lot of fun to look at it this image took a long time to generate cuz it was very messy but it came out really nice you can actually see the icing on the on the cookies right um so the other thing so we talked about introspection introspection allows you to learn abuse documentation potentially to extract things that are not meant to be so openly documented the other um common attack pattern is batching and nesting queries so um the the flip side of having uh this precise querying utenation and stuff is that uh you can also overload queries a lot and cause denial of service stuff so batching is

when you add a lot of queries of the same type and you get the the API to honor them in such a way that it scales resource consumption in an uncontrollable way and the other interesting angle to think about uh batching is if this um if this uh invokes the infrastructure in such a way that components are moving in parallel to to to um honor request then you might be able to batch in a race condition depending on how that how that works I don't see I don't think anyone's done that in public research but that's a cool idea and obviously batching and nesting means you can brute force in interesting ways you can get it to honor

guesses for let's say authentication um and you can pack in like a 100 guesses per request which is way different if it doesn't honor those right like um so for instance some I don't know if this is making sense but some graph queries allow you to log in through the query and that means if you can batch theer where you can brot force the the the login the other thing is nesting we'll see an example of this nesting just means uh you embed queries infin item so that it it has to relook up these values the whole time and um batching queries is is pretty straightforward so um it looks like this you take a query and you

stick in a whole bunch of questions and see if it answers everything I don't know if there's a better example than this um pretty straightforward you don't need a big IQ to understand why that would cause problem lots of queries lots of compute lots of problems um and then the other one is nesting and circular queries um I did I unfortunately didn't flesh out an example of circular queries but I did show you a schema and it does make sense why that would emerge you could have one type that uh so this is a good example I think of of sorry this is nesting this is circular not nesting it's circular because you can look up

the authors and the authors in the schema allows you to look up the posts and the posts allow you to look up the authors so you can just rinse and repeat this lookup to make like a massive request and if the the person who developed the resolver wasn't smart enough uh to defend against this it means that every time you pull an author it's got to pull a whole memory uh author object out of memory for every single uh time you you perform the query which would be the resource scale cost would scale um exponentially really fast um and this is Alias overloading so the other thing you can do is you can slap an alias or a keyword onto to a query

and uh the reason you'd want to do that is because the engines that receive the query might be smart enough to cat the query the the query that you send so if you send the same one the whole time you're just going to hit the cash one way to get around that is um to add Alias so you can say alas leite uh this is my question Alias one this is my question Alias 2 this is my question boom boom boom boom you can you can stack up a lot of a lot of queries for the same thing um and the engine will treat it as a unique query um so yeah those pretty much the

the most exciting things to talk about thus far about graphql I hope uh I hope I had enough fancy things to say this is a list of the tools I've uh I've looked into that I think are competent enough competent enough the problem with gra tools is that they're not very stable and they don't receive a lot of love for a long time so the stuff you run into will probably work for a little bit but you'll see like for instance gra grainder which is made by the vks at Escape was quite a prominent Tool uh a year and a half ago about but they stopped developing it completely and I think they funneled all of their um

developer effort into the paid uh service that they offer now so graind is cool but it's not doesn't receive any any any love lately so it's a little bit weird to trust it on your pains graphel cop's pretty nice I think it's really good tool it's really good tool for quickly figuring out whether there's Alias batch Al whether aliasing is allowed circular quaries or batching is allowed it just splits out out immediately so this is nice and scal able and if you want to make an automated tool around graphql graphql cop is is a really good um Contender and then uh I think the paid service that one hears people talk a lot about is

escape. Tech you pay a bunch of money they scan it and they handle the problem yourself if you're an or organization that can do that um I think it's a good tool but yeah um so far I've been I've been having fun with the scripting stuff so um defenses I think are pretty straightforward uh you can Implement them at the mid uh I mean this is the interesting thing because some middle wear rate limiting protection will not protect against some of these attacks right like you you can send one request the rate lieming will allow it but the back end will be producing a lot more noise so sometimes traditional rate limiting will help you but I think the

best defense is to make sure that your specific implementation you're aware of the the the depth limitations and the size limitations on queries they've all all the engines have responded to this some of them have built in have built-in uh responses but yeah if you're going to deploy graphel please make sure you don't uh open yourself To Deni of service attacks and of course uh the the the other point is deploy a firewall and get folks like me to look at your stuff regularly um so yeah for the and again the last slide um I thought was a good thing to mention is uh some of the stuff we're missing in the graph tool set is

better fuzzing capability so like I think I see a lot of stuff where people can extract scheme and bold requests for you but no one's doing really uh intelligent fuzzing of a schema like if I give you a schema can you produce oratory sentences in this language at infinum like this is a good way to test how you're how you're passing anding queries the other thing is better automated exploitation so we have SQL map for GR for SQL stuff but I don't see a strong equivalent to to graphql unless unless I'm missing something so something where I can just push button it collects all the data and has optionality around the different exploitation capabilities um

particularly switching between like if I have a graph ul and I numerate all the stuff and I find the SQL injection bug what do I do with that like there's nothing where I can exploit the Synergy between these two um as far as I know so yeah um and that's it um thanks for listening

across the attack surface scattered products and siloed views create blind spots that feel Unstoppable the deadliest risks are in these gaps where attackers move in it's time to unify fragmented snapshots into one allseeing view of risk and unleash a platform born with one intention isolate and eradicate your priority exposures from it infrastructure to Cloud environments to critical infrastructure and everywhere in between this is tenable your exposure ends here