OWASP Top 10 in GraphQL: An API Adventure

uh the talk coming up now uh is OAS top 10 in graphql an API adventure and uh Danielle Rosenfield LEL is going to present it for us now um thank you so [Applause] hello um and just a quick check um can everyone hear me across the Brom excellent I know that it can be a little bit um you know hard at the back particularly if there's a lot of noise outside I was listening to One um yesterday right um so this is a was top ton and graphql um thank you for coming so I try not to lay with this point too much um for those I haven't met yet my name is Danielle I work as a

pentester um I tend to have a pretty firm preference for working with web Technologies and I'm dabbling a bit in um cloud and also you know secure code review at the moment um and when I'm not penetration testing I'm a very proud cat mom to two extremely spoiled cats um and I knit prolifically wherever I can so um this is the the overall summary um I had a couple of ideas in mind when I put this talk together um and really one of the primary targets um for this talk with people who were dabbling in security just getting to know the field a little bit um so firstly um web applications and apis are really the bread and butter of what a

penetration tester does day to-day a lot of the work coming through is going to be looking at web Technologies and um these topics aren't necessarily always given the level of enthusiasm they deserve um and so following on from that for anyone who has an interest in security and and sort of wants to get you know a bit more acquainted with um with web Tech OS um is something that comes up frequently especially in um job descriptions when you're looking for employment um so a knowledge of the top 10 is very important um and um and often very topical and so I sort of thought well it would be really cool to do a run through of one of the oos top 10

listings um focusing on a slightly less commonly encountered technology and so that's what I'm going to be doing this morning uh we're going to be looking at some graphql Theory um so graphql is going to be our way of of looking at oos top 10 we're going to be introducing the AOS oos top 10 API security risks and then we're going to use both graphql and a deliberately vulnerable graphql app as a vehicle for discussing um the top 10 and specifically before I go any further um when we talk about top 10 we're usually talking about top 10 for um web application um which was released in 2021 um but 2023 we had a um an API

security risk listing so I'll be working off of that slightly more um recent listing of security risks for API specifically right so that's all great but what's graphql and um I'm glad that someone was thinking it um and graphql is just one of many options that you have um for helping your web front end talk to a backend server in a fairly control base so we're having um two technologies that are you know um enable to communicate with each other we've got an API implementation strategy in this um and graphel is a cool technology it's very wide supported across a range of Frameworks and programming languages pretty much anything you could want to develop in at the moment you will have

an option to develop a graphql API um and it's actually been around for quite a while even though it um it tends to to feel like a fairly new technology it was developed by U meta when meta was still Facebook back in the dinosaur age um so in 2012 and it's particularly graphy um because you define this um API schema or structure that turns out looking like some hierarchical tree like thing um so you really have this encompassing of objects within objects eventually terminating in fields which are the concrete data that you're defining um so in the example diagram we've got um query which contains a cat um very topical for me um and the cat may or may

not choose to have an owner and if it's lucky it has its own fish so this is where it gets a little bit more interesting from a testing perspective if you've done some application testing but you've mostly seen um rest apis so off the bat I absolutely don't mean that you have to choose between restful and graphql um but there's one notable differentiator in the graph ql case um and that's that um you only have one end point when you're talking to a graphql API you're interfacing um with that that one end point um where in the rest case um you um you have resource orientation um so a core tenant of restful if you haven't um

studied restful um in a theoretical sense is that restful apis are resource oriented um so you have one unique URI per resource um and so in the example provided we've had things like dog um and you might want to talk about a specific dog by ID you might want to talk about that dog's bone and so on and so forth and the thing is that as soon as you end up with an even slightly complex system that you need to represent you can end up with a lot of end points and when you have a lot of endpoints um you need to be thinking about um future refactoring of all those endpoints and you need to be able to

keep a track of all of those and and maintain your inventory um on all of those end points so that you don't accidentally leave something juicy hanging out on the internet um so a a really notable security win just off the bat for graph one Endo um a little bit less Inventory management in some respects so from here on just touching on a little bit of mission critical graphql theory um so first concept um I'm talking about today is schema definition language this is the way that we're talking in our graph QR API um it facilitates transmission of um of information in the API in a human readable Json like language um and this is what means that graphql can be

implemented in this really language agnostic way um where you have a graphql server that's going to talk um was going to be able to communicate um with your queries using schema definition language and in the cat example um we have um we have a definition of an object it's cat um it has Fields um which will be defined at runtime as variables um their name color um and loud and um there are just a couple of type definitions that are worth touching on um so in graphql fields can be defined as objects um so the cat that has an owner um Fields can also be um concrete data um and those are scalers in um graphql scalers is a

very broad church it's not just numeric data it's um strings booleans floting Point numbers um and integers and um one more type definition so um you have the ability to Define enum in graphql so that means that you can um you can actually self-define a list of um of named values so in the color example we could redefine that as an enum we could select beige white black whatever so concept the second is how to do crud um so what I'm talking about is core API operations that facilitate persistent storage of data so create read update and and delete um and the two more commonly encountered operation types and graphql are um query and mutation um query handles um reading of

data so if a user wants to breed U sorry wants to access their own account data they're going to be using a query operation type um and mutation um which handles all data change so object creation deletion and updating of um of the variables associated with with an object that we're changing um and just for awareness there's one more operation type and graph URL that's subscription that handles circumstances where you have some need to um do real time updates on um on a system so you might have like an an emergency notification system through SMS or something like that um it's a little bit less applicable for the um for the purposes of this talk um so I'll just leave that

there as is and as a bit of a heads up from here on in I'm going to be looking at some request and response pairs from Dem vable graph app which is credited at the end of the presentation so I promise nothing but the silliest of examples for the rest of this presentation um and um and we're going to be talking about them in terms of um o top 10 for API now um the good thing about D graph app is that for anyone who hasn't done API hacking in the background before um it's really easy to set up locally just using a publicly available Docker instance um and for a bit of context as

well um what you're looking at um in terms of what this application represents as a public messaging Forum so you can um post public comments um private comments um and in this context they call them pastes so I'm going to align with their language and use pastes is is what I'm talking about so an example um this is a query operation type um and just noting the use of the query keyword we've read all public pastes from this system and this is a mutation operation type um so again um this is what's used to to change um data or in this case create an entirely new object so this is a new public Pace that's been created

using again that um that mutation operation type um that's referenced now the third uh the third course concept I'm going to touch on today is introspection which is really important in graphql um so introspection in a computational sense we're talking about you know um something that's very much like personal introspection where you're looking inside thinking about your thoughts and feelings and processes um and um analyzing why you have them so um if introspection is enabled it allows you to directly query the schema um and get all of the information you need about how to um use the API um and um and what queries you can run and in graph um introspection is enabled by

default okay and here's an an example um request response pair where we've actually run an introspection query um and just with that one request we've been able to um capture all of the information about like the defined types um that we have for this API um so it gives you a really good understanding of of um what you can do functionally with this API and um for a bit of context as well if if you haven't done API testing um this is something that could actually take days um if if not quite a lot longer for a really complex API in the rest for case because you're having to actually do content Discovery across all

of those endpoints in the first place and in this case it's actually been handed to us on a platter which is really cool okay so moving on to the top 10 content um so oasp stands for open worldwide application security project makes heaps of Publications um very famous for their top 10 um for web applications last updated in 20121 there are a couple of really notable strengths of os documentation in my opinion um and they are that firstly um obos documentation often tends to be quite um directed towards developer audiences um and as such um another really core strength is that issues in this listing and in other listings tend to focus a bit more on um root causes um

and also business logic failures um which is notably different from some Frameworks which focus more specifically on vulnerability classes so I'll get straight into it now and moving on to API 1 which is broken object level authorization um also known as B historic known as um idor or indirect object references um it involves some improper ability to read or change something at the object level and as an example I've got this public paste and it's by khen it turns out that there's a really easy to enumerate object ID associated with this paste and you find out that you can actually mutate the past and Def deface anyone's public past across this entire system because there is no authorization

control in this lab environment um so that's that's a clear failure API 2 is broken authentication and again um because this is a lab environment with a relatively simple architecture we actually really don't have authentication in the first place which makes it really hard to tie a user's identity um to some sort of session ID um but as a bit of an example of of what this might look like so login authentication failures can be things like login bypass particularly or if you've been able to change the value of a cookie um in a way that's that's given you excessive privileges um so I've taken this cookie for instance and originally I found this graphic ql

development environment it's part of this environment um and that's really cool because it allows me to run queries in a very user friendly way and do tab order completion to um to look at all the types and all that sort of thing um and you can simply um go in you find that there's some sort of access control on this system you can't run queries out of this environment in the first place um but simply by changing the value of the cookie from disable to enable um suddenly you've you've bypassed the the only thing that looks vaguely like any sort of authentication or or authorization control Now API 3 um is the second of the specifically authorization failures

in this listing um and so what if I want to see every other user's public IP address in the system and it turns out I totally can um which sounds very bad um so um broken object property level authorization um occurs at the level of a um a field or specifically a variable um within um within your object um and um there are two sub classes of of this problem so the first is excessive um data exposure which is clearly what's happened here um the second slightly more interesting one is mass assignment which comes up all the time um in API testing where you have some hidden parameter or field that can be identified and um potentially

manipulated in some unintended way and in um lab contexts often you'll see that as a there's a role um parameter for instance and you can actually change the value of of role to something like admin um where that role wouldn't have been introduced in in the first place in your request um unrestricted resource consumption is API 4 um so this is where you can tie up computational resources um to create a denial of service um or potentially you can cause truly excessive use of of payers you go resources um dialing up operational expenses for an organization um and graphql has a couple of particularly notable susceptibilities um to this issue the first um susceptibility is that you can query

batch in graphql um so that means you can essentially just stack a bunch of queries into the same request and that ultimately means that you can bypass um restrictions that would be um applied so that you can um limit the number of requests that you can can have sent um so you're basically just stacking all of these requests into the same you're stacking all of these queries rather into the same request um and sending them off at the same time and in graphql they're going to be processed in parallel um so all together all at once um and then the second notable susceptibility is um denal of service by recursion um so because we have this

sort of hierarchical um tree likee structure we can really Nest queries within queries which can make for something that's really resource intensive um potentially causing a denial of service and the good news on the other hand is that we have a couple of um variable documented workarounds to to all of these um these things so you can for instance um add um limits to the maximum query depth your process and that can address the deny of service by recursion case um you can apply request timeout so if the request takes more than a certain amount of time up to a fixed limit we're just going to drop it we're not going to process it anymore um you can um also uh

return cach responses so that you're not having to reprocess the same query um that might be particularly popular multiple times and finally um you can apply cost analysis to a query before it's processed so we're going to actually factor in how resource intensive that query is in the first place before we even process it um just an aside as well that that can actually be fairly computationally expensive and slow down your response time in the first place so you have to apply it on a case- by case

basis and api5 is the last of the authorization failures um in the list of 10 so imagine that you've left some absolutely Godlike operation um accessible that was meant to be used by admins so something that's a specific sort of all over the system functionality um and in the example it turns out um that you can make a call to delete all pastes um and thinking that it was just my own public paste that I'd be deleting I run this and it turns out I delete everyone's um comments across this entire system ever um so then moving on to API 6 um unrestricted access to sensitive business flows this occurs where you have um some ability to um trigger

sensitive business functionality um in an you know using an automated tool um so for instance I've been able to spam this message board with 100 comments um this is a really really really silly um example however something that's a little bit more topical um at the moment might be where you've had um Bots used to to purchase concert tickets to scalp so if anyone was looking for ears um tour tickets uh that was that was very much in the media um recently and very much a problem um now making sensitive business processes multi-step um can make this sort of exploitation harder um where you're not just having to triggle one single API call um but as an aside um an attack can

very easily use a script to automate a multi-step process if they care enough about the Target in the first place um so it really requires a more comprehensive solution Now API 7 is notable because it's the only specific vulnerability class that really gets touched on in this entire list of 10 and that service side request forgery which speaks to how important it is um service side request forgery where can access um you can use a um part of the application to access some Network resource um in an unintended way so you can access things that are internal restricted um and in the example I've used a vulnerable um file import functionality to actually access a um a web service running on my

local device um and as as a bit of background um as well uh in real scenarios this this level of um of easy is is basically you know not something that I've ever seen um but you do get a lot of inference-based suicide request forgery um issues cropping up where um where you have to do quite a lot of additional investigation um API 8 is security misconfiguration a tremendously broad Church um introspection remember her she's back um so turns out um perhaps we' been able to um Identify some very very secret administrative functionality um that ideally shouldn't have been handed to us on a platter as a hacker um AP9 is improper Inventory management um phenomenally important um

that's where we have some poor visibility over what a product does um where there are two subcategories um of this this issue um defined in in the oos documentation um that's where you have some documentation blind spot um is the first um where documentation either hasn't been generated for a product in the first place or it hasn't been maintained after it was initially published um and data flow blind spots um potentially where you have some sort of data flow between your app in a third party service but you have pretty poor oversight over what that um that data flow actually looks like what it does and whether it's Justified from business perspective in the first

place and finally made it it was a bit of a mouthful um so API 10 is the last um of our API or whatp 10 um risk categories now that's unsafe consumption of apis um and I didn't have a particularly good example of this in a lab context and I imagine virtually in any lab context because um you end up with these pretty simple architectures um but this occurs where you have an interaction with um with third party Services again um and you've provided excessive trust to that third party API um so for instance you might consume data from a third party API without any input validation leading to um injection vulnerabilities on your application um

or you might share sensitive data with a third party service and you don't check that that third party service applies the same rigors of um protection um to the confidentiality of the information you provided so in conclusion um uh graph is really really cool um it's very flexible um it's elegant it has fantastic support um and a particularly notable difference from test perspective is that you're interacting with a single endpoint as your interface um OS top 10 um unsurprisingly applies just as much for the graphql case as it does for other API architectures and um there are just some notable differences when you're testing graphql um because of graphql like works like introspection for instance using

mutation for all data change um and how much Direct Control you have within the query over the application logic um um and I don't think we're necessarily going to have a lot of time for questions but but I'll leave that up to Josh and res [Applause]