State of GraphQL Security 2023

hello everyone so today uh we will talk about uh graph qu security and we will dive in the report we published about the topic um we also have a few surprise at the end so stay tuned um uh first we will introduce uh Escape so at Escape we're building a fully automated uh security platform um so the interesting point is that we are totally agentless and uh so it work only with input domain um and an authentication strategy if you want to go deeper in your application um it scape is know for its unique IP traversal algorithm we will go deeper in the subject later um and uh we're actually capable of testing business logic and not uh simple fuzzing through

reinforcement learning algorithm um with that algorithm we will generate a legitimate sequences of request and uh exploit complex attack scenario and chain attack such as ssrf and stuff um we're also known for our recent work about attack surface management so you have a lot of input here but attex for management consist of referencing uh any end point exposed on your on organization uh just like Google search hold index uh an application um at Escape we do have a team dedicated to finding new vulnerabilities zero days um finger printing engines uh on graphql and rest application and continuously improving this algorithm that so you can see the here um all right uh so let's get right into the report of security

topic so we scan 1,600 API endpoints um each of these endpoint were publicly accessible for legal reason I guess and um so that represent a cumulative duration of 460 hours so that's a lot of computing power at a lot of cost if you are on AWS um so we collected almost 47k uh security alerts which is quite a lot um on average this is 30 alert per graphql end point um so this is really interesting if we you if we do have some people in bugun here because uh we will present you some specific graph findings and some CV we reported um it happens that sometime people tag us on aank and Aur one to say okay there is some Kudo

for the CV you published I just got got bunci for that um so if you wish you can already scan the C code or take a picture of it if you want to access the complete report later on um but let's introduce ourselves so here is go is full stack engineer at escape and he is also leading the web application uh team and I am Swan I am security software engineer I am leading the cyber security and A&D part and if you are stuck in your CTF I am also experiened in binary exploitation well thank you SW for this introduction uh first let's let me ask you by raising your hands who is familiar with

graphql oh quite a lot actually that's great we'll start by introducing this technology named graphql and explaining what it is vulner why it is vulnerable by Design graphql is a queral language uh built around types and Fields rather than end points this uh allows uh front end developers applications to query exactly what they need effectively moving from the back end for frontend Paradigm sometimes may uh some types sorry May expose other types uh through their fields effectively creating a graph data model it was designed and used internally by Facebook since 2012 and uh was made public starting 2015 and companies uh get started to get attracted from Fortune 500 to startups there's another reason why

graph is getting popular is uh the the graph model allows creating some kind of API gateways effectively exposing underlying uh apis built with different Technologies or graphql or rest whatever uh by grouping uh these the all the data the underlying exposes inside a big graph with uh joint concerns such as

authentication here is a rather complicated graph query which allows me to in produce uh some well vocabulary a graphical query starts with yeah perfect uh in the top left corner uh an operation there are two main kinds of operations queries and mutations we can loely map those to queries map to get request get HTTP request and mutations to http post requests uh we will detail all the other kinds of tokens in this query uh when we will talk about the vulnerability they imply there are two interesting metrics uh regarding graphical queries the depth the depth is the level of nesting the well the level the deepest field in the query and the width is the total

number of fields in the query we said graph model here is a representation of a dummy graphical API and let's say for instance we have a type on the right hand side exposing a strip token field and a path in blue leading to this field well since our data model is a graph there may be several path path leading to this field for instance a shorter one here in red and a longer one in Branch effectively creating some kind of Access Control nightmare I guess that's your turn so now we will talk about the Escape magic and why is it hard to test production application um but um it's a fundamental problem uh it's not specific

to graphql any application is hard to test dynamically um so first only a very few companies uh how they integrate automated uh Dynamic security testing pipelines um this is becoming uh more frequent with uh so compliance and uh compliance in payment system and compliance in general um secondly most of um security solution use fing algorith them so sometime fing algorithm are really simple but sometimes are really advanced uh if you take for example um ledgers and stuff uh they will use a lot of uh fuzzing testing really Advanced and uh anything that is coming to Binary exploration exploitation is about phing but um IPI is quite different and um often security solution do not pass

the validation layer and so they never test the business logic whereas most of security vulner ities are present so that's why we developed a unique algorithm that we call feedback driv exploration that is specifically designed to learn about the application about its business rules and the way it actually organize object um this system was specifically designed to work on graphql but uh we reach the state of the art in that field and we are no testing it on different protocols such as rest or grpc application um to explain it really simply we will go to the next slide um so you can take a look on that part you will see that you have way more coherent

data than on the other one um so on the right side you will find a query that is totally uh randomly generated and on the other side you will find uh something which looks like a u ID an email which is very likely to be gathered from the application and you also have an injection in the password um so Escape is scanning in two different steps there is a first step where we g a lot of data from the application trying to understand this business logic and we will change a very few things after that to um test about vulnerabilities if some of you knows out there with B Bounty testing um you can see Escape as like nucle on a really

really strong steroids with this feedback driven um exploration algorithm um so as just mentioned graphql is a graph and resources are all organized as a graph so it's becoming um very hard to automatize that with a software um because application can be very huge with f duration and stuff um we today have algorithms that are capable of operating both deep and wide and actually testing all path all parameters and all objects in a graphical cha um that is not an easy journey to manage this recursive

beavor yeah so we build a complicated algorithm we make it run on the internet uh with what we found more than 40 thousand alerts uh which we will review one by one right now no just kidding here is uh what we found grouped by categories uh in this big list there are graph specific errors vulnerabilities and some kind of vulnerabilities that has existed uh since apis uh existed for instance uh publicly available stack traces and safe fruits uh graphical injections let's take a look at the this first tree to begin with uh here is a graphql server which has its debug settings uh still on on production and it's about 12% of all graph C end points we tested and and why

is it a vulnerability because some St stack traces uh just dumps Library versions for instance the server is using a deprecated library with a very critical not I cve on it the next one is uh unsafe fruit being public which means uh in fact that uh the the mutation which can affect edit data on the server are missing some Access Control last but not least we found many Esq injections they are still there one bash common injection which means we we can just run code on the remote machine and three Ser side request forgies we were able to intercept machine to machine Communications to leak some API secrets more on that later now let's jump into the graphql

specific uh vulnerabilities we group them in four categories API broad foring denial of service uh API schema leak and unsafe public operations uh the first one API broad forcing leverages a feature or two features actually named batching and Ling which can by Design uh group several graphical requests in a single HTTP exchange making the whole exchange faster on the internet because some web application firewalls uh count requests at the HTTP level it allows an attacker to run some kind of Brit Force attacks to run for instance three more three or more login attempts in a single HTTP request effectively by passing rate

limiting so here is a quick conclusion of the consequences you can have through boot procing so stolen user account because you can um actually uh brute force and say okay I will try uh uh 10,000 of uh pin password tries in one request and because I bypass the rate limit and you can extract sensitive data using such techniques um uh yeah and this feature aliasing when coupled with another feature named graph file uploads can lead to an a modern version of Z bombs we named it graph bombs uh for instance let's consider uploading a single file of one megabyte but if we reference it a thousand times in the request with a one megabyte HTTP

exchange we are able to create one gigabyte of work on the endpoint so we can add grav qu bmps to the list of consequences this time for you um okay all right for the second vulnerability we'll talk about den of services and we will take fragments as example so fragments is another feature of graphql um you can see that as a function if regular programming languages um so I may ask you what could go wrong if you have a language that is recursive by Design if you implement uh function in it so let's get an example of that um so this is a very simple example uh we're declaring a query which called a fragment X we're de declaring a fragment

X which called fragment Y and and so on so congratulation you made your first infinite fragment recursion Loop um so this is an updated stack Trace so most of uh JavaScript base and python base engine don't want to actually um cover these cases because it's handled by the language Safeguard on recursion uh but still you get an interesting stack Trace um let's uh think about compile languages because this thing is in the graph say so compile languages such as goong and rust uh do not support um this at all um so if you use rust here um my team and I made rest more secure because we publish multiple cves um so this is a

different attack but still on fragments you can check check on GitHub advisory if you want the detailed explanation um so we're only disclosing the ones that do do not affect graph rfc's and are related to the implementation itself depending on the languages um so in that specific example just to be quick we nested a lot of fragment together and uh we lead to memory overflow and uh took down any rust server almost in instantly so um as I said we made a lot of contribution to JavaScript engine and Java engine which is used by most Fortune 500 um and so at Escape we do run into a lot of zero days but we are always

reaching graphical foundation and maintainers first before disclosing uh consequences of denial of service could be an IP availability for some time and a total IP shut down um so the third uh interesting vulnerability specific to graphql is schema leak um so graph qu provides some introspection capabilities but you can disable this feature to hide your um schema but uh with another graphql feature suggestion uh you can um rebuild the schema from scratch um so with f suggestion any misspelled query will be corrected to something that actually exist in the schema even if the introspection is disabled so um that is an example of schema we reconstructed to Clarance Clarance is an open source package that

you might be using already if you are doing a bug mes on graphql um we contributed a lot at escape on this package uh this is totally open source um so there is a iCal example in that specific Shema on this side you have the schema that we found through the introspection and someone just uh thought it was interesting to hide update inquery uh because it wasn't protected so we changed the password and someone was not happy um yep so we highly discourage uh considering security through obfuscation because pentester are uh always capable of restituting such information um so we can see the consequences of schematic access to aniz function that you previously hide and

easy confirmation because if you have an update admin query you just have a back door in your

API we also found a shovel full of publicly available information in two big categories piis personally identifiable information and tokens API machine to machine uh tokens among those in the Pia category we found a lot of email and phone numbers which are which can be which could which in this case could be false positives like support address emails support for numbers sales phone numbers Etc but that was never the case for uh passport numbers and bank account numbers which are which are far more critical far more critical on the other hand we manage to dump a lot of uh machine to machine tokens like a uh Amazon web services tokens Google CL platform tokens uh

private RSA keys and certificates and O tokens to Adobe as GitHub and even one chat GPT token all these graphical specific vulnerabilities these four categories uh can be linked to the more common top West top 10 vulnerability classification that Tobias showed a while ago for instance the dust and complexity issues fall under the API o4 category Access Control fall under all the Access Control uh OS top 10 categories o1 O2 and 05 and security misconfigurations and information disclosure disclosure uh fall into the APA 07

category to sum up what you could read uh in the report we found uh more than 100,000 public graphical ipis on the internet uh through gethub searches Google searches only oint uh we narrowed this list down to a, uh a bit more than a thousand uh based on two Criterion uh they need to be publicly accessible without any kind of of authentication so that's the UN dedicated Criterion and have their introspection have their introspection open which means that we can get the whole schema from the API without needing uh to reverse engineer it uh with the suggestions for instance all the vulnerabilities you saw uh some are graph C specific which can be the most devastating ones but some

are as old as the internet and Dena of services are possible quite easily by default because graphical engines feature no OD limits on gra uh query depth and query width which can lead in the case of a graphical gateway to a single point of failure because you're able to down the Gateway you able to down all the

infrastructure you can scan the K Cod to download the whole paper you will get more informations on the 46,000 alerts we did not detail which makes a lot of pages

and all right so let's see how we are trying to make the web app ecosystem more secure so not specifically graphql and uh that is a few surprise weal about at the start of the talk um first we can uh tell you about graph armor graph armor is a completely free and open source package um that is a on line installation and for JavaScript based and gines um you can remediate to a dozen of graph Cur specific vulnerability such as so IIs limit character limits depth limit and F suggestion and and so on so check that out if you are like a graphical developer or trying to improve in bonti um so just type graphical armor and if

you want to make a contribution we always accept contribution so as I said we recently extended our algorithm to rest application so we did the exact same um report on rest application um so we published a website called I I.D um we ranked every apis on on different criterias but uh so we scanned again the internet trying to find unauthenticated and public API you have for example Spotify SoundCloud Etc um um so we had mind that if you come to choose your next payment solution you could choose between stripe checkout.com and and so on so we ranked every API using different criteria such as securi so compliance with oasp top 10 performances so pure speed reliability

um and design is your application commented and so on and we still found an interesting token in all these ipis GWT emails and uh because it's really interesting because it's uh super recent we found a few open AI API Keys um for the numbers we scan 6,000 over 6,000 API we found a bit less of vulnerability this time because we didn't add the graph Q specific vulnerabilities and uh if we have some devops writer we you also have the technical specifications

and last but not least we are launching a free completely free uh API Security Academy which can be accessed through this link it's a platform to learn about API security uh using both approaches first a red team approach so you get to learn about the vulnerability you get to learn how to exploit it and then you take the blue team approach uh you have to patch it and effectively prove that your the vulnerability is patched what's interesting about this site is that it runs entirely in your brother you got a full uh njs uh development environment working in your brother through web containers so it can work completely offline thank you for your no not yet ah

yeah here is the details of what a lesson looks like it's a complete integrated developer environment with a file system uh the explanation of what the vulnerability is usually small yeah what's wrong yeah uh small servers with one specific vulnerability yeah so take a look it's open source it's on GitHub and it's currently on beta uh please file bug reports so that's all for today um we're uh still Hing if you are interesting in cyber security software engineering or fullstack web development uh we're based in Paris so if you want to visit friends that could be a good opportunity and AR our Andel if you want to add on L jeans and mail um and uh maybe meet again at

some conferences thanks

thanks thanks guys for traveling to be with us here today that was great does anybody have any questions hand in the back coming back keep it up where was the hand yes you sir hi guys thanks um so first first of all your research is based on the apis with uh which all have introspection open right yes so would you consider disabling introspection a must in this case as a step one to protect the API and how much would it make would disabled introspection make your work more timec consuming um so as I said with schema um even if the introspection is closed uh we can reconstruct the application uh so I won't go too deep in this uh part

but so we contributed and made clance open source most of the code is writen by Escape guys but um you could always with some complex NLP algorithm uh fall back to rebuilding a complete specification even if the F suggestion is closed there is some eristics available out there but um that's and other stuff so basically you consider disabling introspection a security for obscurity right yeah it it okay it doesn't work security bi obscurity uh is not recommended at all you shouldn't consider it also if your uh API has a front end the front end will contain some graphical queries that you can already take as a base of knowledge to create more complicated queries any other

questions looking up at the balcony no okay are you here for the rest of the the day and hopefully the evening thank you so much to goer and Swan