Nick Aleks and Dolev Farhi -- GraphQL Security

0:00Chris RomeoDolo Farhi is a security engineer and author with extensive experience leading security engineering teams in complex environments and scale in the fintech and cybersecurity industries. Currently, he's a principal security engineer at Wealthsimple. He's one of the founders of DEF CON Toronto, DC416, and he enjoys researching vulnerabilities in IoT devices, participating in building CTF challenges, and contributing exploits to ExploitDB. Nik Alex is a leader in Toronto's cybersecurity community. and a distinguished and patented security engineer, speaker, and researcher. He's currently the Senior Director of Security at Wealthsimple. He leads his own security firm, asec.io, and is a senior advisory board member for HackStudent, George Brown, and the University of Guelph's Master of Cybersecurity and Threat Intelligence programs. Nick's also a founder of DEF CON Toronto. He specializes in offensive security and pen testing and has over 10 years of experience hacking everything from websites, safes, locks, cars, drones, and even smart buildings. Dolev and Nick join us to unpack the world of GraphQL security. We introduce GraphQL, threats to it, and mitigations for how you can secure your GraphQL instances. We hope you enjoy this conversation with Dolev and Nick.

1:17You are now listening to the Application Security Podcast brought to you by Security Journey. When you finish this episode, check out our other show, High Five, to stay up to date with all the hot AppSec news.

1:28Chris RomeoHey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo. I'm the Chief Security Officer and Chief Strategy Officer at Security Journey, and I am also joined by my good friend Robert Hurlbut. Hey Robert. Hey Chris, yeah, it's Robert here, and I'm a Principal Application Architect, Security Architect, and I'm also a Threat Modeling Lead at Acquia. And both Robert and I are coming to you from glorious, glamorous hotel rooms from around this good United States. I'm in Austin, Texas, getting ready for LASKON, which starts in about 2 days. And yeah, so that's kind of getting to see the world a little bit, see a little bit of the security world now that the conference scene is back in full swing. So I'm excited to hear some really excellent talks there at LASKON. I know, Robert, you'll be doing a talk here as well, an excellent talk. on DevSecOps and threat modeling. I'm talking about Security Champions. So 2 different things that both of us really have a passionate passion for. So we're joined today by Nick and Dolev, and we're going to talk about GraphQL, which is something that I've actually been really looking forward to having this conversation because I really want to learn about this. I feel like I don't know very much about GraphQL. Like I could maybe answer the question on Jeopardy!, what is GraphQL? Maybe. but maybe not as well. But before we do that, let's go ahead and hear some security origin stories. So Nick, let's kick it off with you. Tell us how you got into this crazy, wacky world of security. Yeah.

3:06Hey, everyone. So my name's Nick, and my security origin story goes way back to high school when I was playing around with a lot of tools like backtrack and try to break into my Wi-Fi and my friends' Wi-Fis and just be able to say like, yeah, like I got in. And ever since then, you know, I then diverted over into mechanical engineering where I went to school for specializing in drafting and design. And a friend came over one day in the middle of my studies and he brought over some lockpicks and was just showing me how he was like breaking into certain locks and deadbolts. And that just like immediately sparked my curiosity and allowed me to go from like, okay, I'm going into mechanical engineering. I now see that, you know, actual physical pen testing is a thing. And so from there, I really dove deep into pen testing. I especially, you know, started to get things like the snap gun, under-the-door tools, and got heavily involved in that. And then I realized that working and partnering with other pentesters and security professionals, I was able to really grow my chops in the web application hacking space because being a developer is something that was also a big passion of mine. And yeah, from there, then I ran into Dolev and we kicked off a little thing in Toronto called DEF CON Toronto. And I guess the rest is history there.

4:44Chris RomeoYeah, it's cool to hear how lockpicks played a role in your origin story because, you know, we've got all these groups now that do lockpick village style stuff and lockpick experiences at different conferences. And it's definitely an interesting way to unlock people's minds to, you know, how to take things apart and ultimately put them back together. you know, by using those types of tools. So that's really cool to hear. So Dolev, how about you? How did you get into security?

5:15So my journey with computers goes way back, but my first, I guess, security-related thing that I ever did involved Sub7. I was experimenting with Sub7, which was kind of weird because it kind of, if I remember correctly, it also involved like ICQ numbers. And it was like, I think the first time I ever tried hacking hands-on. And later on when I started developing a career, I started in DevOps. And I was part of a DevOps team at a company called F5. And I was kind of in charge of handling security for appliances. And then I decided that I want to focus only on security and ended up actually relocating to Canada. where I met Nick. And ever since then, I was like 100% full-time only doing security. And I wasn't necessarily focused on one area. I always wanted to learn everything that I found interesting at the time and never wanted to actually focus on a niche. So the whole GraphQL journey is actually the first time I ever focused on a very specific piece of technology. And yeah, I've been hacking on different things, smart buildings with Nick as well, GraphQL stuff, a lot of authorization-related projects, side projects like web application pen testing. And yeah, and right now at WallSimple, we're doing a lot of GraphQL-heavy things, which led to everything that we're here for, which is hearing about GraphQL stories.

7:01Chris RomeoVery cool. And let me just, let me just make sure I tell our audience here how we got to this conversation was you guys have written a book, Black Hat GraphQL API Attacks for Hackers and Pentesters. And so that's, that was kind of what caught my attention. Nick had posted something on LinkedIn about it and I was like, hey, I want to learn about GraphQL. And so the book is coming, it's coming soon, right? The book's not out yet, but it's coming soon. When is that going to be available? Yeah.

7:30So, the book is available right now for early access and preorder at the No Starch Press website, or you can just go to blackhatgraphql.com. The physical copy will be available, I believe, in like Q2 of next year. So, that's how you can grab a copy.

7:50Chris RomeoOkay, cool. Yeah. We'll put the links in the show notes so people can get to that directly so they can order a copy of the book. So Robert, why don't you kick us off with our— into our GraphQL journey here? Sure. You know, I've seen GraphQL when I was using some security tools. I never heard of it before. So for our listeners and watchers today, Nick, could you tell us what is GraphQL and what are some use cases?

8:21Yeah, for sure. So GraphQL is a relatively newer API technology that's used by a lot of really big, big companies these days, such as Netflix, GitHub, Wealthsimple. And the whole premise of GraphQL is to allow customers and API clients to essentially grab the data that they want and that they need from the server. Now, this is a little bit different from your traditional REST API endpoints that we're all pretty familiar with. But there's issues with REST APIs. And the issues that get, you know, brought up all the time are these concepts of under-fetching and over-fetching. And so you can imagine hitting a users endpoint and getting a whole bunch of data about users. Now, this is definitely not a problem for hackers, but when it comes to developers looking to limit the attack surface and the data that they're grabbing from the server, it's pretty important to only grab, let's say, the emails that you want or the date of births. And GraphQL allows you to unlock it. The way that, you know, I kind of have heard about GraphQL is that it's very much like, you know, trying to go to a vending machine. And, you know, when you want to grab a particular order, you can actually just like put in your coin and, you know, punch in the thing you want and you get, you know, the data that you exactly need. And so the other problem is the under-fetching problem. And a lot of REST APIs will, let's say you want to grab some login history for all of your users. If you went and you tried to first go into your histories table, you'll see that, oh, you need to first pass in a bunch of user IDs. Where are you going to get user IDs? Oh, so you have to first go and query the users endpoint, get a bunch of IDs, and then pass it over to like a login history endpoint. And then you can see how multiple calls are gonna make things inefficient. GraphQL solves that by allowing you to essentially stitch together all of these data sources into a single thing called a schema that's held on the server side and actually sometimes presented to clients, allowing them to pick and choose the data that they want and how it's related to other pieces of data in order to respond back to. to clients. So that, in a nutshell, is what GraphQL is. There's a lot of nuances to it, but that's the use case and the main problem that it does solve for most folks.

10:56Chris RomeoSo, Dolev, I'm gonna send the next question your way here, but this is kind of helping me understand GraphQL a little bit. So, you know, when I think about query languages, I think the one that I understand the best, as well as probably most of our listeners, is SQL from a structured query language. So is there any compare— can you compare SQL and GraphQL? Is there any connections or any similarities between these 2 things or are they completely different?

11:27Like, yeah, there's a little bit of similarity, but they're really different. I think like GraphQL is— the things that you can query are based on something called a schema. So if you're a client and you want to like read certain things. What gives you the ability to read or write certain things is basically something called schema. And that's your representation of the data. That's how you expose certain queries. And in GraphQL, you have basically 3 main, like, operations. There is a query, which is actually just called query, which is what you would use to read data. You have a thing called mutation, which is how you would write data. You can also write and read at the same time, which is—

12:10Chris RomeoOh, okay.

12:10how, like, one of the things that are nice about GraphQL. And there's also a third thing called subscription, which is more like a real-time, you know, server push type of updates over WebSockets typically. So, these 3 operations give you the ability to do certain things against a GraphQL server.

12:31Chris RomeoOkay.

12:32So, you would typically define something called a document with a bunch of fields, and those fields could have like subfields. So if you kind of compare that to SQL, um, I wouldn't say that the, like, the syntax is similar or the language is similar, um, but it's not like extremely different. Um, and, uh, it takes like those queries that you're using can also take variables and like arguments and things of that nature, similar to how any other API would work, just structured a little bit different. Yeah. So, to answer your question, I would say it's not similar, but also it's not that far.

13:19Chris RomeoOkay. So, got it. That's helpful to understand kind of this foundation. Now I feel like I've got a solid foundation of GraphQL and what it is and how it works. So, now let's get into some of the fun stuff as far as the threats that exist against GraphQL. And I'm sure there's, I'm sure there's quite a long list along the way. But Dolev, why don't you kick us off and, and talk to us about threats?

13:46Cool. Yeah. So there's a lot of different things in GraphQL. Despite the fact that it's an API technology that allows you to typically do the same things that you're used to with other technologies like REST, there's a lot of fundamental differences in GraphQL. There are threats, and I'll try to tackle that from 2 different directions. I'll start with the blue team. Some of the challenges that blue teams will face are things related to observability and the reliance on certain things that exist in like HTTP requests that they are used to in order to see if something is going on from like anomaly detection standpoint. So when you query a GraphQL endpoint, you're only querying a single endpoint as opposed to REST where you have resources and routes. So you would typically have a single endpoint and that— so basically the client intention is not based on the path. It's based on the payload itself. Where in REST, you might see, say, if you have a POST request to /v1/users, maybe somebody's trying to create a user, right? The combination of the method and the path.

14:53Right.

14:54That's not the case in GraphQL. In GraphQL, the case is you have a single endpoint, could be like a /graphql, could be a /query, could be anything. But the intention is based on the payload, which is the actual query. And the method in GraphQL is always, typically always POST. So if you look at blue team tooling, what they would see if they were looking at access logs is like a bunch of POST requests to a single endpoint.

15:20Chris RomeoOkay.

15:22all returning the same status code, which is kind of bizarre when you think about it from anomaly detection standpoint. Status codes in GraphQL don't have a meaning typically. So you would always get a 200 and the errors to your query. So you make a bad query or your query resulted in no results, the error will be in the payload itself as opposed to the status code. So these fundamental differences are something you need to think about when you adopt GraphQL. GraphQL has 2 major problems and they fall under 2 categories. One is authorization issues and the other one is denial of service. GraphQL is unauthenticated by default. So meaning that when you build an API, you have to do all the— take all these extra steps to figure out how to do authorization. And denial of service comes from the fact that the client is the one who's deciding how the response is going to look like. So when you do a GET request to like v1 users in a REST API, you're going to get some kind of payload. It could be a JSON with a bunch of keys like ID, email, first name, last name, so on and so forth. But GraphQL, you are the one who is deciding— the client is the one deciding what type of information the server is going to return. So it could be just the ID, could be an ID and an email. And since the client is in control of the response format, the client can request a lot of different things. And, and one of the things that is special about GraphQL is that you can essentially stitch multiple schemas. So imagine you have a microservice environment and you have a bunch of services, all are behind GraphQL, each with their own schema. Maybe one is around accounts, maybe one is around, I don't know, transactions, different services. But you can expose those under a single schema. So you basically take all these small little schemas, make them one big schema, and expose that as a single API. So clients can actually create really, really complex queries that could result in many, many, many joins and things like that that would be very hard to process if you requested a lot of different information. Because that query could result in like many backend calls to many, many different services. So denial of service is one of the main pain points of GraphQL just because the client is in control of what the response format is going, going to be, which is quite unique as well. So I would say from everything that we've seen so far and, you know, the research that we've done as well as looking at other public reports of other people, The 2 main categories are authorization issues, either like bypasses or lack of authorization in general, and denial of service.

18:16Chris RomeoHmm. Okay. So Nick, I want to, I want to kind of get your take on this. As I'm hearing Dolph talk about GraphQL and some of the threats between authorization and denial of service, it just makes me think about like in the OWASP world, we've got the OWASP Top 10, we've got the OWASP API Top 10. Are there any of those same things that exist in those OWASP top application security risks that are applicable to GraphQL outside of authorization and denial of service? Are they, you know, are things like SQL injection, cross-site scripting, you know, those types of challenges, are those things that can weave their way into GraphQL?

19:04Oh, yeah. Oh, yeah. 100%. GraphQL, by no means is it immune to traditional attack vectors that, you know, like REST APIs are vulnerable to. You could potentially use GraphQL arguments and variables to inject payloads that a server would not be able to necessarily know how to read or respond to correctly or expose vulnerabilities in the business logic layer. So injection is a huge concern and a huge issue when it comes to GraphQL. We wrote a tool called CrackQL that allows you to actually do some automated fuzzing and injection-based attacks. It's used to actually brute force a lot of in-band authentication workflows. And so you can just pass it a whole bunch of arguments. And if you wanted to, you can pass in a couple of cross-site scripting injections, SQL injection vulnerabilities, and see exactly what type of outputs the GraphQL server is giving you. So that's 100% an issue with GraphQL. It is not solving our traditional attack vectors as the OWASP Top 10 has shown us. If anything, you know, as Joel is speaking, the one thing we want to really say is that it gives the clients a lot of power and a lot of control. And that's something that a lot of GraphQL API maintainers, implementation contributors all need to really understand is that that freedom comes with it some pros and some cons. So, there's a lot of unique risks as well that Joel have mentioned, but a lot of the traditional ones are still also very much vulnerable in a lot of GraphQL implementations.

20:59Chris RomeoYeah. I mean, as a security person for a number of years, to hear the description that, like, we're putting all the control on the user side just kind of makes me go, whoa, wait a second, hold on. Can't we bring it all back to the server side and just lock it down and where we can control it? But I get you know, the use cases for this technology are driving the need to be able to control things in the client-side, user side. But it's, as you're saying, it's also opening up some unique risks. So Nick, another question for you from, how are people attacking GraphQL instances? Do you attack GraphQL through another application and kind of proxy into the GraphQL, or do you go directly to the GraphQL source? and attack it like you would any other external API?

21:50Yeah, this is a good question because GraphQL can really be implemented anywhere within a company's infrastructure. A lot of the times they will implement a GraphQL API server at their gateway. So, you know, facing the public, allowing customers to directly interact with their schema and get information about it. But GraphQL can also be implemented within the internal infrastructure of a company and of a network, allowing for microservices to talk to each other, grab data that they need, sort of having like a different type of domain gateways, if you will. So if you are attacking GraphQL, you'll most likely want to look for a couple of endpoints such as like a /graphql or api/graphql. Now, it's unlike REST APIs where you've got like a lot of different endpoints. When it comes to GraphQL APIs, you only have to deal with one API endpoint usually. But once you get access to that API endpoint and, you know, let's say there's no authentication or authorization behind it, you can immediately start to send a couple of queries to the actual API server. Now, Dolev and I also wrote and published the Damn Vulnerable GraphQL API application, which you can use to test and hone in on some of your GraphQL attacks. So that's one really great resource for folks who want to take a look at how to attack GraphQL. But for the most time, for the most part, if you If you look on HackerOne, or if you look at a couple of other bug bounty programs, you can see that there's a few companies that are starting to make their GraphQL API endpoints public and also in scope for a lot of their testing. Okay.

23:46Chris RomeoSo, Dola, if you had a, from what I understand, found a zero-day in the GraphQL spec that impacted all the implementations. So tell us, tell us that story.

23:57Yeah. When we were working on the book, we were reading the GraphQL spec, which is essentially like an RFC type of document. It tells people that want to develop GraphQL servers how to do that, what type of validations need to be there, what type of things the server needs to return. And most GraphQL, the mature ones, follow that.

24:19Okay.

24:21But there is also some things that are lacking in the document in terms of security. It doesn't say anything around security at all in any parts of that specification. If you just do a Ctrl+F and look for security, you will not find anything. So there's a lot of things there that you ask yourself, okay, what do I do? What can I do if given a certain scenario? So there is a concept called directives in GraphQL. And directives can be applied to schemas on the server side, but they can also be provided by the client. And directives allow you to do certain things depending on where they are. So just to give the concept, the general concept of directives, like you could have directives that control authorization. So imagine that you have like a schema and you define like a user with the email. So like I mentioned before, a schema is a way for you to expose the type of things the client can query. So you can control within the schema who can access what. So you would use directives for that. It's like the symbol. You can, you can say @auth, and then you can say which groups can access that particular field that you want to control, you want to protect, as an example. So that would be a schema directive. There's the concept of client directives, which is again the symbol and some arbitrary string depending on how you named your directives. And that allows clients to do certain things. So as an example, imagine that you have an IP address field that you query, and that IP address field gives you, like, I don't know, just any arbitrary, like, private IP.

25:54Chris RomeoMm-hmm.

25:55And you can pass a directive, say CIDR, to that field, and it would return the CIDR format of that particular IP. So you can transform the field that you're querying by using directives. That would be, like, a classic example of why you would use directives. So you can change, like, formatting, you can I don't know. There's a lot of different examples of how to use them, but the concept of directives allow you to control certain things and change format of different things. So directives have a mention in the GraphQL spec, what they are, how to implement them, but there's no, like, mention of how many should you accept from a client or any mentions on how to secure that whole thing. So when you write a GraphQL query, you can pass many of them. There's no limit on the amount of directives that you can send on the same type of field. So we realized that when you pass many, many, many of those, thousands of those, like @symbol, let's take network as an example. @network, @network, @network, @network.

27:08Okay.

27:10and you pass 1,000 of these, that's going to consume a lot of resources from the GraphQL server. And there's no mention of security around it, how to protect against it. You would be— it's going to be challenging to figure out how to actually protect against that. You can approach it from different angles. You can, for example, with a web application firewall, drop requests that have a really large payload body as an example. You could, during the parsing, you can just drop it if you see like many of— there's different ways of doing it, but you will have to implement all of that yourself. So it's really tricky to actually protect against that as well. So we realized that passing many, many directives really consumes a lot of resources. And we saw that a lot of open source tools, like for example Magento, that use GraphQL, vulnerable to that thing. And there was a— when we started the disclosure process, there was a lot of different takes on, is this an issue? Is this not an issue? Who's in charge of protecting against that? Is it the job of GraphQL? Is it the job of another security control? So during the disclosure process, we realized that there's a lot of different opinions on, is GraphQL the place to enforce security or is it the job of another tool?

28:33Yeah.

28:35Which was interesting because people, some people within the GraphQL community don't think that it's GraphQL's job to protect the API. They think that it's possibly another tool's responsibility. Same thing goes for authorization. Some opinions, some people say that authorization should not be the responsibility of GraphQL. It should be a responsibility of another system. So there's I think since GraphQL is relatively new, there aren't strong opinions around security, where security should live, how you should do security for GraphQL, and it will take time for that to evolve. So that issue may have been fixed in some of the companies that we disclosed that issue to, but it's still pretty much out there because it's just part of how GraphQL works.

29:23Chris RomeoSo, Double, with that in mind, you talked about authorization, you talked about denial of service being some threats, and of course, a zero-day. What are your thoughts then or recommendations for mitigations for those threats in GraphQL?

29:40Yeah, so you have to first assume that when you deploy GraphQL, it's unprotected by default. It's flexible, it's gonna give you all the ability to query the way that you want. That's the status quo. That's the default thing that you're going to get. And in order to combat malicious queries or malicious clients making really complex queries, there's certain approaches that were developed on how to rate limit GraphQL APIs. One approach is to statically analyze the amount of fields that a client is requesting, put some number or weight on those fields and have a maximum threshold and drop the request if it exceeds that. So if you request, like, for example, a user and then their ID and email, maybe the whole thing would be a 3 and that would pass because you have a threshold of 10, as an example. So you would statically analyze the query and make a decision whether this is too complex to process. This is more on the denial of service side of things and less on vulnerabilities like injections and things like that. There's another approach where you could do that dynamically. So when you request a field in GraphQL, say user's email, you're not necessarily gonna get one email. You might get the email of all the users, right? So the fact that you requested a single field doesn't mean that you're gonna get a single field in the response. It could be an array of different things. So the If you think about it, like the compute power that the server will use is not necessarily going to be defined by the fact that only a single field was requested. There is a possibility that thousands of resources are going to be returned by that single field. So another approach is to analyze the response. The challenge with that is that you have to first process the query and then see what the response was on the server side and then make a determination whether that was a expensive or not and then assign a cost to that. So that would be another way of tackling this. When it comes to injection and the type of vulnerabilities that we're used to that are not necessarily like authorization or denial of service, it's not gonna be that different in REST APIs compared to REST APIs because GraphQL can take parameters and values and of different types. The nice thing that GraphQL will do for you is it will do— it's strongly typed. So if somebody for example, is passing an integer instead of a string, it's going to fail early. But if you have an argument that is of string type, then you can obviously pass a single quote or dash dash and things like that. It's not going to fail. But if you provide the wrong type, it will fail early. You have that in GraphQL. Web application firewalls is also another interesting area that's started developing in the GraphQL space. Companies have started tackling that area, making their web application firewalls more GraphQL aware, as an example. And web application firewalls still apply in GraphQL space, especially when it comes to things like cross-site scripting and injection and things like that. At the end of the day, the web application firewall will see, I don't know, 1=1-- or something. It's going to block it whether it's GraphQL or REST API because it's just a string that exists the document. So that's still relevant in the GraphQL world. Lastly, what I want to say is authorization is a big issue because you can get to the same type of data in GraphQL in multiple ways. It's a graph. So for example, you could get an email from a user, but you can also get an email from other ways as well. For example, if you have, like, I don't know, I'll try to think of a good example here, but Imagine you want to get the emails of all the users on the website, but you also have a way to get your own email. So you might have a user's email, but you also have a me email. So you can get your own email. So you get to that same data from 2 different directions. So you can apply authorization on both of them or at the root, depending on how you implement authorization. And if you implement authorization based on the path, then, and you have multiple paths to that same data, then you end up with a lot of opportunity for, like, authorization bypasses. That's one of the issues with GraphQL.

34:13Chris RomeoSo it's almost like a, you know, when I think about microservices, for example, like one of the challenges that I've seen with microservices is you'll often get different security controls implemented in different places. And so while it's not a direct correlation, it sounds like GraphQL has a similar macro-level problem of you can come to data from different directions and you may be able to— you may have a security control that you've thought through the way you think people are gonna access the data, but we know attackers don't ever— they don't ever follow the rules, right? They always try to find ways to circumvent. And so you may not have that same control on a alternative way to access the data, which could then get you in trouble from a GraphQL perspective. So input validation and output encoding, all those type of things we would normally— all the things we would normally tell people to do for a web application, Nick, are the same things. You got to do the same things if you're using GraphQL or whatever your backend is.

35:18Yeah. The other thing that I wanted to also jump in and add is that a lot of security teams and security professionals may blindly trust that the monitors and the observability controls that they've put in place are going to protect their GraphQL workloads, when that's really not the case. So for instance, if you've got a particular monitor that's reviewing logs and it says, you know, if someone's trying to log in we get, you know, X number of 403 error response codes, let's go ahead and, like, ban or rate limit that particular client's IP address. That logic doesn't really translate very easily over to GraphQL. In fact, like, if you have a lot of, like, status code-based monitors that, like, wake up your security team to, like, really check something out because you're being attacked, that doesn't— that does not work. Because when you look at a lot of GraphQL and implementations, they're all, you know, being sent with a POST request and they all pretty much respond back with a 200 error or 200 status code, regardless of if there's an error in the payload or not. So a lot of these like monitors that we've built traditionally in our security centers on the ops side will need to be reevaluated and rebuilt for GraphQL. So, another key piece is, like, build your observability and build better logging around, like, the types of GraphQL operations that are happening to your production instance. And from there, start to build additional monitors to detect when attacks are happening and try to also prevent them.

36:55Chris RomeoNick, so, tell us about the book and tell us why. Why did you guys decide to write this book now?

37:05Yeah. So, you know, Wealthsimple is definitely a company that's adopted GraphQL. And, you know, it was one of the main hot topics. It solved a lot of the performance issues that we've been seeing with scaling up a lot of our microservices and solving that under-fetching, over-fetching problem that I shared. And as we were adopting it, our developers were really gung-ho about implementing it.

37:29Yeah.

37:30Dolph and I really like to take that offensive approach to securing our infrastructure and our applications. And we saw that there was a really big lack of knowledge and resources with GraphQL security, and especially on the offensive side of like how to test it and ensure that it's hardened. That's sort of an approach that we really like. You know, if we can hack it, you know, we kind of feel like we've got some assurances in place that the defenses are working.

37:56Chris RomeoYeah.

37:56working. And when we noticed that there was really nothing out there, we said, okay, well, this is an area that we're gonna have to start to research a little bit. So, we spent some time digging deep into the spec, building tools, really testing our own implementation. And we said, you know, why not just like grab all of our research and all of our data and knowledge from hacking GraphQL and put it into a book? And our goal and intention was to allow us to essentially, like, give back to the community with a tool and a resource that we didn't really have when we were first trying to defend and attack GraphQL. The book is intended to turn someone who, you know, may know a bit about computer science and a bit about REST APIs, but knows nothing about GraphQL and can really ramp up quickly with, you know, understanding the language, building an internal security GraphQL security hacking lab, as well as get a plethora of tools that we recommend in the book that we've written, and that we also highly recommend to attack your GraphQL APIs. And so you'll learn things like how to do proper reconnaissance, detect if a particular company is running GraphQL, what endpoints they might be behind, collect information about what type of implementation or what type of flavor of GraphQL it's running as well. That'll allow you to curate and conduct specialized, very tactical attacks against it. It'll also allow you to then take that reconnaissance information and start to, you know, play around with that GraphQL instance. So try to send some injection attacks, try to, you know, bring the server down. So, the book is intended for someone to go through the entire pentesting lifecycle for a GraphQL asset that's being tested, and really turn folks from zero to hero in the GraphQL hacking space.

39:57Chris RomeoVery cool.

39:59Very cool.

40:00Chris RomeoI'm looking forward to diving into it and taking, you know, my knowledge to another level. I think I feel like I've learned quite a bit about GraphQL just in this conversation as well. So, to kind of wrap up our conversation and land the plane here, I wanna go to each of you and ask for a call to action/key takeaway. But I'm gonna steal the most easy one just to put you guys on the spot. And so, my call to action/key takeaway is for our listeners to grab a copy of this book and dive a lot deeper into GraphQL. So, Dolev, coming to you, kind of what's your one call to action or key takeaway then for our listeners, other than buying a copy of the book?

40:40If you work at a company and they're thinking about adopting GraphQL, because that's a very typical pattern where you have, like, a hot technology and suddenly a lot of people wanna try it out and adopt it, really think deeply about how to protect it and whether you'll have the tools necessary to protect against that. You wanna have feature parity or, like, support for the same type of things that you would have for your REST APIs to your GraphQL APIs. And there's some lift in there as well. So once you understand GraphQL, you learn, you don't have to necessarily buy the book. We have a lot of open source tools and resources that we've built, but we highly recommend it. Make sure that you have the necessary tools from rate limiting perspective, from log analysis perspective, from alerting perspective that can help you get your GraphQL APIs to the level of your REST APIs.

41:32Chris RomeoVery cool. Nick, I think Dola took all the key takeaways and call to actions, but maybe you got something else.

41:40I've got a pretty, like, good high-level one for the community and for developers and companies. And it's essentially, you know, just because everyone else is adopting a technology, is implementing it in their production environments. These might be companies that you look up to. Doesn't mean you should just blindly grab the technology and start adopting it and pushing it into your production instances. Really, you know, continue to evaluate the third-party applications and libraries and tools that you're implementing into the services and products that you have to offer your customers and test them robustly, as robustly as you can, and really question adopting a new technology and spec, especially if there's not a lot of information and background in the security considerations for that technology. So that would be like my high-level one is, you know, I know that everyone really likes to adopt and move, you know, at the speed of technology. But sometimes we do need to press on the brakes and really get a good understanding of what the risks are when we are adopting new tech.

42:50Chris RomeoYeah, I think that's great advice from both of you. So, Nick, Dolev, thank you for sharing your GraphQL knowledge and a lot of the things that you learned on your journey to securing GraphQL. And I look forward to taking a look at the book and diving even deeper into this topic. So, once again, thank you for sharing your experience with us today. Thank you.

43:12Thank you for having us.

43:13Thank you for listening to Security Journey's AppSec Podcast. You can find us on Twitter @AppSecPodcast, on LinkedIn as the Application Security Podcast, or on the web at www.securityjourney.com/resources/appsecpodcast. Find Chris on Twitter @edgerau and Robert @robertherwett. Remember, there are many application security paths, but only one destination.