Ashish Rajan: Hello, welcome to another episode of Cloud Security Podcast . This is September, and this is a new month and we are talking about modern security stack this month. Basically we have been talking to a lot of people over a lot of conferences. We did RSA AWS re:inforce, Defcon, Blackhat. And one of the obvious conclusion that we keep coming back to is the modern security stack is a lot different.

And when I may mean what it’s different. Evolved quite a bit for years, but I wanted to reintroduce what a modern security stack looks like at least in 2022, especially towards we come to the end of this year. And we’re already in September who new. So October, November like is ending very soon. So one of the important things in a modern security stack these days is through how to handle APIs, API, or application programming.

I. A lot of people may already be aware. We use APIs in AWS, Azure, Google cloud, but a lot of web applications that are hosted on these cloud services are also using APIs to do backend conversation. so for this episode, we had Corey ball. He is a senior manager of pen testing at Moss Adam, [00:01:00] and also the writer for hacking API book, which is a, quite a popular book.

If you haven’t checked that book out, you should definitely check the book out as. During the episode we walked into, what are some of the common best practices that people should be applying to API security these days? And what are some of the mistakes that people see are as low hanging fruits in the space that people should totally avoid?

And if you are a pen Chester who probably has been doing web app testing for a long time, And you’re right to find out how is it different to do web app versus API? This is a perfect one for you as well. He also spoke about the top 10 OWASP API vulnerabilities and why the number one is still the number one and why he sees it so often as well from a blue team perspective.

It’s really interesting for me to hear. How can something as simple as a swagger file, rest API, GraphQL, what are these things and why a pentester would approach to exploit them, or maybe even least to highlight the fact that, Hey, this should be done a bit differently. I hope you find this episode helpful.

And as always, if you know someone who’s probably looking to do some [00:02:00] work in the APIs space, or at least APIs security, Definitely check this episode out and share this with them as well as it also helps us get the message out. And if you’re someone who’s listening to the podcast episode for the third of the fourth time, while working out, or while walking your dog or while doing dishes or something else, I would love to hear from you.

And thank you for supporting us all this while I really appreciate the review and the rating that you give us. And I really appreciate all the YouTube subscriptions as well that you’ve been giving us. So just to check out the video version, thank you. And I will see you later in this. With the new episode on the modern security stack in the September month, talk to you, then stay safe and enjoy labor day for people in the US.

I hope you have a great long weekend with family and friends. Take.

Corey Ball: By bringing developers and security together, you don’t have to choose between speed and security. Develop fast, stay secure.

So my name’s Corey ball. I’m currently senior manager of penetration testing over at Moss Adams and there I perform. Various [00:03:00] penetration testing with

Ashish Rajan: Hey, how’s it going? How’s how you man going.

Corey Ball: Well, how about you?

Ashish Rajan: Good man. Good. And thanks for coming in. I appreciate this, man. Thanks. No

Corey Ball: problem. Thanks for having me.

Ashish Rajan: Yeah. Well, I think I’m gonna jump straight on, cuz I would think a lot of people know you already through your book, but for the one or two people who don’t know who Corey is, if you just give a short intro, about yourself and how’d you , got to your current role or , what yor’re upto these days man?

Corey Ball: Sure. a team there of consultants. So we’re working with different clients in different environments on a weekly basis to test out their networks, web apps, APIs so on and so forth.

And. I’m I’m here because about two years ago I began work on a book called hacking APIs, which came out July 12th this year. And yeah, that book is a guide that I needed about two years ago to learn how to pen test and find vulnerabilities within application programming. interfaces specifically [00:04:00] with web APIs rest and graphql.

Ashish Rajan: right and you have the book in the background as well for people who end up watching the video. There’s a, yes. That’s, that’s pretty much a copy of the, that’s not the only copy. That’s just the copy that you have. That’s right. fair enough. So, and I wanna get into straight into the APIs space and before we kind of get into it and to level the plane field, cause a lot of people listening to this may already know about API.

I’m sure they have their own questions about how to do API security or at least an opinion about it. However, a lot of people still are oblivious. . And how would you describe APIs and why is it important in 20, 22 and moving forward?

Corey Ball: Yeah, so I, I do get that question a lot, especially friends and family that may not be technical.

So they’ll normally ask, oh, what does API stand for? And I, I start with saying, well, it’s not gonna help you too much that it stands for application programming interface. So , what APIs are there are a couple of metaphors that really help with it. Would be Legos. So if we think of all these different applications that are out there, they’re the center piece of the Lego.

What APIs [00:05:00] are, they’re the connection pieces at the bottom and the top of the Lego that help things connect together. And so APIs enabled applications to that are on various different programming languages that don’t necessarily work well together. Yeah. To use the web HTTP in a specific configuration in order to interact with other applications.

Right. So APIs facilitate that communication between different apps.

Ashish Rajan: I love the Lego analogy as well as my dog box in the background as well. How is API different in web? You know, how come I’m using a cloud security podcast and now more and more organizations talking about having API and it’s usually related to cloud is your regular web app.

Like isn’t that HTML, like how is API coming into this? I sound like you were dumb, as I say this.

Corey Ball: Yeah. So HT APIs are using HTTP to have a common language for crud. So [00:06:00] creating, reading, updating, and deleting resources. And so HTTP has been around for a while and these various programming languages have interacted with that.

And so it’s just the common language to request resources from different URLs and paths. Yep. And using different HTTP methods to do.

Ashish Rajan: The reason I kind of ask that question is because you know, the, most of the people, when you tell them, Hey, I’s a web app in their mind, they’re going, oh, you have a Java script.

You have like a, it’s a web app. And you kind of, I know maybe you have a few things started. There’s like a local database and the browser or something like. People when they think about at least a lot of people that I talk to. So is another way to put it is API what’s using like the backend conversation, like, or what do you see it in the front end as.

Corey Ball: Yeah. And so what we’re seeing on the front end is typically in a browser over a graphical user interface, APIs are communicating from machine to machine. So it’s all happening in the background. In a web app, if you were to go onto twitter.com or a different web app then what’s going on [00:07:00] is. you hit that URL with your browser and from your perspective, all of the information just seamlessly loads onto the page.

But what’s really going on is in the background. A whole bunch of requests are being issued. Maybe there’s a different endpoint. That’s powering the feed of text that’s going into Into your Twitter homepage, maybe there’s another endpoint that’s hit up for videos and images. And those are just a bunch of requests that take place in the background that seamlessly fill the page.

But if you’re sitting there and proxying the actual requests you can, you can see behind the scenes of what’s going on with the API.

Ashish Rajan: Awesome. And I think quite a few examples already there in public about it as well. I think one of the one is the all the public cloud browsers as well, like figure to Amazon Azure or Google cloud when anyone is clicking on, Hey, I wanna start using this compute service or this store service.

That’s pretty much the same thing over there. And , it’s fascinating how quick it works as well. So not since we update the [00:08:00] foundation for what an API. Let’s start with what are some of the common, best practices? Cause I feel like, because you’ve been doing this for some time, you wrote the book and even though it’s launched in this year, it’s still so popular in terms of conversation.

But actually the good example is says we were at RSA a few months ago. Mm-hmm and one of the team was talking about API security, but it was amazing how many people did not know API security, cause from their mind. Well, isn’t that just. I asked for something kind of what you were saying as well.

It’s like I asked for something text here, text back, like text, text out. Why is that a bad thing? Yeah. So , I’m curious from your opinion, like, what are some of the let’s start with? What are some of the bad things you’ve seen in the API space?

Corey Ball: Sure. And just , your experience at RSA was my experience two years ago when I was voluntold to like, you know be the leader in API penetration testing for MOS Adams.

Right. And I went to those conferences and I, you know, went to all those elite pen test talks and different things like that and said, you know, what are you guys doing? And essentially they had the very same [00:09:00] opinion where it’s like, isn’t that, you know, you’re just making

Ashish Rajan: the, to get stuff. Yeah. Like why, why do, and I.

Did you find that like when we spoke to Amazon or , anyone else, a lot of the knowledge is say, why don’t you just use a WAF like that’s all, but I’m like, but there’s so much more than a WAF in an API. And I don’t know if you agree or disagree with it, but I’m curious from your thought, so what are people doing , wrong, and why is it something that requires more.

Corey Ball: Yeah. And so what we see the most of matches up with the current OWASP API security top 10 list and the number one item on that list that we see often is broken object level authorization. Yep. So authorization vulnerabilities are everywhere and yeah, it may seem like the APIs are this input output sort of deal.

When it’s a stateless request, then the API provider has to use something for authorization. Oftentimes that takes the form of a token. And so. The API [00:10:00] provider is checking to make sure a user is authorized at all. Then that token is great to say, yep, this is a legitimate user. They have a right to be here and request this information, but the next check that is often missed that we see a lot is that that user that’s tied to that token.

Should only be able to access that user’s resources that first check takes place where it’s like, yes, they have a valid token, but do they have a valid token that should be able to access those resources? And so we end up doing a lot of user, a user B testing, where we make a bunch of requests from that user, a account.

We find the resources tied to it. And then we go back with a user B account to see if we can access those. And that’s where that vulnerability lies is that. You know, you and I are both using the same app, but I’m able to use my valid token to request your resources.

Ashish Rajan: Ooh. And it wait, so it’s number one in

Corey Ball: that list.

It’s number one. Yeah, it is. And for the [00:11:00] right

Ashish Rajan: reason. Yeah. Yeah. Okay. And so you see they’re often good and wait. So is it that hard to fix? Is that why it’s too common or why do you feel it’s common?

Corey Ball: I, I don’t know. I can hypothesize I’m on the pen test side, so I do a lot. Oh, right. Fairness, the braking and, and everything else.

Yeah. So I. Can try to put myself in the shoes of the devs, but I’m not too sure. I, I do know they’re pretty good at doing that first check. You know, if I’m making a request for your resources, but I don’t do it with a token at all, then I’ll, I’ll get blocked with a, a 4 0 1 response that says not authorized.

But that check that says, Hey, I do have an authorized token. So maybe there’s some layer of trust that’s involved. These are our trusted users. They have a token they’re valid. Yeah, yeah, yeah, yeah. Missing that second

Ashish Rajan: check or even API as well, I guess. Cause to your point, the scope could be limited just to an individual or a team.

I imagine that’s where, yeah. Well, I don’t wanna make it too technically complex for people who are trying to listen to this conversation as well. But so to your point, if [00:12:00] sounds like that’s a pretty common, low hanging fruit that people should definitely try and avoid. What do you recommend people?

I imagine there’s another side of people who come to you as well and say, Hey man, what’s the best practice for this? Like, , what’s the thing that should be doing, which I don’t do or which all the people are not doing.

Corey Ball: Yeah, I, I don’t know why on the web API side of things that it, it seems like one solution is it, but , it’s the same as network security where a layered approach is always gonna be the best way to go.

Mm-hmm so , you mentioned WAF earlier in WAFs are great. It’s a good thing to have in place. It does a lot of good block and tackling for some of those low hanging fruit. If someone that’s an authorized user. Sends over a very obvious request with a sequel injection, then it’s gonna get caught by that WAF.

And they could be blocked. Their token could be banned. Their IP can be blocked, all that stuff. Yeah. But when they’re an authorized user making. A legitimate request. So me making a request for your [00:13:00] resources, if they don’t have the logic to determine that user shouldn’t access user be resources, then that WAF isn’t gonna help too much.

And so that’s having that layered approach where you’re not just, depending on that one security control is gonna go a long way.

Ashish Rajan: Right. That makes me even curious. So what’s the most surprising thing that you’ve found in the pen testing you’ve been doing so far in API’s

Corey Ball: space? Yeah, so on the authorization side of things, it’s one thing to be able to access other users data, but there’s also another.

Authorization issue. That’s classified as broken function, level authorization. And I use this example a lot, which is from real experience, which is broken object level authorization is the ability to see the Maybe, if we’re talking about a FinTech API, it’s the ability to see how much you have in your account.

So from my perspective, as user a, I can see into user B’s account and see how much money is in the account. But broken function level authorization [00:14:00] is the ability to transfer the money using the API from one account to another. And that’s a very real issue especially on the FinTech side of things.

So, oh, that that’s one that’s surprising, you know financial institutions that have a lot of money to invest into security. And do you know, they’re blocking and tackling with their network security, physical security, everything else, but then a new API is introduced and something like that is coming up on, on a test.

That’s pretty significant. Yeah.

Ashish Rajan: Alright. I’ve got a question here from Gemma as well. How to find API keys. how do, how do you approach this?

Corey Ball: Yeah. So this is in the API hacking process. This is gonna take place during reconnaissance most of the time. And so there’s a variety of methods that you can use.

Google dorking Git dorking that are gonna be pretty successful at finding leaked API keys. And then later on in your testing, you’re taking those and then trying ’em out and seeing, you know, have they expired? Are they still valid? [00:15:00] And that’s a good way of going about it. Tools like truffle hog two, I think truffle hog is a great one.

That’s gonna scan and find those for you. But I guess you probably wouldn’t be too surprised, but if you do some quick searches on GitHub, you’ll find a lot of leaked API keys, whether it’s actually in an issue or it’s actually in the code still you can find ’em all over the.

Ashish Rajan: Awesome.

Hopefully didn’t answer your question. Thanks for that question. Jema. So, alright. We spoke about the most surprising thing with the FinTech API that you example that he gave us, we kind of mentioned WAF as well, that another commonly seen I guess. Software API gateway is another one which kind of is seen quite often in a structure.

Like in my mind, when I think about APIs, I’m usually imagining it there’s a wave , to your point of a layered approach. A lot of people would just stick with having an API gateway, which kind of is like a one to many approach. You get one request, but it’s just going into spring many API calls or whatever.

But, or sometimes people would put a WAF in front of [00:16:00] the API gateway sometimes come through the WAF like what are your thoughts on the whole, whole API gateway as a security control point?

Corey Ball: Yeah, I think it’s great. I think it does. As a single security control, it does help a lot with some of those vulnerabilities.

So it can help with the authentication process but. You know, there there’s a lot of room for error still in those. So , if it’s using, I mean, if it’s using JWT, those could be misconfigured in 15 different ways. And so it can help with the authentication process. It can help as a single portal to access , the variety of microservices that might be behind that.

It also. Is pretty helpful on the rate limiting side of things. So you could specify how many requests the API consumer can request you a specific service, which that’s helpful for blocking one of the top 10 and also on the blocking side. So once a user. Broken the contract or gone beyond their request limit [00:17:00] or anything like that.

Or, or if there’s a WF there, you know, a SQL injection attack or something of that’s fairly obvious is detected, then it can be used to block that user’s token. It can be used to block that user’s IP address. So it’s a definitely can be a great layer. Okay.

Ashish Rajan: So, well, so you need both then, I guess you just need API gateway.

Corey Ball: Yeah, no, I think, I think it goes all the way down. Like a WAF is helpful for some of the simple blocking and tackling , the gateway is helpful. You know, it can help on the authentication side and the rate limiting side. That’s great. But then do you have monitoring in place?

Are you seeing if something’s going beyond those security controls, are there, you know, how often do we hear about new ways to bypass? WAFs like it’s almost monthly or so

Ashish Rajan: So to your point then, I guess, cause that’s another best practice. , what we mentioned just before around authorization checks, where people do a great job of doing authentication checks, but authorization is where a lot of people fail.

And to, I guess what I took took away from that is because I guess a lot of people listening to this or [00:18:00] want to get to the point, or what’s the best practice for me to be doing this. So, you know, I can avoid the next Corey trying to , go behind my back, I guess. And , in a good way, I meant obviously, so.

Things like, I guess authentication authorization sounds like an obvious one layered approach to what he said, which is having a WAF and API gateway. Cause there is a whole API security, top 10 as well from OWASP as well. Yes. Which looks very similar to the OWASP Top 10. And is it like, do you find that as well?

Yeah,

Corey Ball: I would say about half are, are shared and the OWASP API security project is actually going through an update this year. I’m not sure if it’ll be published this year, but that’s begun to update it further. So. Yeah. You see some similarities with like injection attacks and broken authentication and logging, but there are some that are specific well, about half that are probably specific to API.

So like improper assets management and mass assignment and the authorization. Oh, I mean like [00:19:00] you have. Some authorization issues on both sides, but those, yeah, there’s some crossover, but definitely referring to that. And yeah, I think defense in depth and taking it as a holistic approach. So, you know, as far as best practices go, having security controls in place.

Great. That’s a good thing to do. Testing. Those is huge and, and not just testing those from like the developer’s perspective, but getting that adversarial perspective is great for detecting, you know, business logic vulnerabilities, the, the variety of vulnerabilities that are associated with the top 10 project.

And and then on the other end monitoring and detecting when an attack actually happens, that’s all good stuff.

Ashish Rajan: Monitor and detecting is interesting one for me, because I’ve seen people use monitoring to monitor the API calls itself, but is there something that people talk about from a security perspective?

You know, how the people have SIEMs and like, oh, you log over here to look for anomaly it’s that kind of the approach for API [00:20:00] security as well?

Corey Ball: Definitely because with a scene like that in place. Specific to the API requests, then you’re going to see that anomalous activity. So if you have 99% of the users make requests in a certain way, and then there’s that 1%, that’s doing some things that maybe valid as far as the current security controls go, but they’re trying to violate, you know, , some of the rules in place , or authorization or different things like that.

Ashish Rajan: That makes me think of the fellow pentesters. Who’ll be listening to this conversation as well. Cause a lot of them, and it is quite well known in the space that web app is probably the most common application that most people out there testing. And they might look at an, I guess, API testing as like, I don’t know what this is and don’t even way to approach this.

So our, those skills transferable sounds like they are based on the Top 10 but what are your thoughts on there and , what are some of the things they could be doing to kind of approach pentesting APIs?

Corey Ball: Yeah. So for me, one of the big, like fun [00:21:00] facts about APIs is 83% of all web traffic is supposed to be API related.

And if, if that’s the, the case really key offend 83%. Yeah. That’s true. Wow. Well, I mean, at least it’s been in reports, so I’m believing those reports that have been out there. Yeah. From like Akamai and different companies. Of course.

Ashish Rajan: I mean, it may sound obvious as well. And most things are on cloud these days and cloud itself and they’re running an API.

You’re making a lot of API calls for backend, most likely, but yeah. Wow. I didn’t know. There was a start out for it as well.

Corey Ball: Yeah. And that one may even be dated. It could be higher by now, but yeah, there’s a lot of machine to machine communication going on that doesn’t even involve, you know Testers in the middle or people interacting with things.

It’s all taking place in the background, but with that much of it, , the web app pen testers definitely need to be confident and comfortable with approaching APIs because more likely than not, there’s going to be an API on the web that they’re testing and. If, you know, web app pen testing has been going on for [00:22:00] a handful of years now.

And so we’ve done a lot of the testing, the documentation , for how to do thorough testing. Some of the books I have in my background, you know, they’ve been out for years and they covered the topic. But , if we’re not evolving to take on, you know, the API requests that are representing most of the traffic that’s going on, then we’re gonna be missing a lot of the weaknesses

Ashish Rajan: in.

Wow. And okay, cool. That that’s, that sounds like an obvious thing. So it sounds like the transferable skills as well. And to your point then approaching API, cuz I’ve , got a question here which is for Jema again. What do you recommend for people learn API hacking. Yeah,

Corey Ball: so I actually just teamed up with a company called apisec and we released the apisec university.

And it’s completely free. You can sign up for it. at apisecu.com and anyone that wants to learn more hands on stuff. It’s a great free resource. Yeah. So my book covers a lot of the API hacking process. It also introduces a lot of the knowledge getting your [00:23:00] hands on the CTFs that are out there. So the OWASP API security project they also released crappy the completely ridiculous API.

It’s a VO. Oh, I thought you said

Ashish Rajan: actually meant crappy am I I’m like the release a crappy site. I’m like,

Corey Ball: yeah. Well, I mean, it is, it is deliberate though. Yeah, so you can check out the. API security project and download crAPI test out various tools on it. And , one of the things that I recommend is a lot of organizations that have had that same perception that like we already have web app security.

We’re already getting our web apps, pen tested. We already have our vulnerability management program that has taken care of that for a while. I recommend downloading. Some of these vulnerable apps deliberately vulnerable. They have all of the top 10 OWASP, API security findings out there. And. Test your current vulnerability management against that, because that has led to a lot of false negatives.

So you’ll use your tools against them. You’ll set up a scan, maybe you’ll use NEIS or burp or zap or something [00:24:00] like that. And you scan these deliberately vulnerable apps that have. Very vulnerable APIs and you come up with little to no results. And so that’s a very scary thing in security to have that false sense of security and maybe not get the budget to have it tested and stuff.

So you wanna be using the right tools and the right techniques specifically for APIs to make sure you’re not missing those. apisecu is a great place to get free resources and get your hands on it. Obviously there’s a lot of great YouTubers out there. Insider PhD has great content. So definitely if you haven’t seen her content, check it out.

Yeah, I think those are some of the

Ashish Rajan: good ones. Awesome. No, thanks for that. That’s pretty awesome resources as well. And I mean, going back to. I, I guess it’s really helpful for people who are pen testing, web apps, and want to go to a resource as well.

So , that definitely answers the question. And maybe if people have internal pen testing teams and they can share this resource with them. So this was definitely helpful. So thanks for sharing that. Now. We spoke about some of the common pen testing things as well that, you know people can actually approach.

With [00:25:00] the cloud because cloud security podcast as well, have you had to ever, like we were talking about this earlier where Amazon Azure, they all are very similar web apps where they use API calls in the background for backend conversation. Have you ever had a chance to kind of do any of the cloud services and do they behave any different to say any web app that you would’ve had, which is on API, which is not on cloud?

If that makes sense. Yeah.

Corey Ball: So from my perspective with testing web APIs, there’s. too many differences on that end. So whether you are on using one cloud provider or another, if you’re attacking rest APIs, or if the API is set up in a restful way, then that’s using HTTP methods and specifically requesting to different paths for different resources and functionality.

So that part isn’t with the different cloud providers, what you do see is maybe that the front gate, you know, is More secure , than maybe a homegrown solution. And so we do see that quite a bit. So , those cloud [00:26:00] providers do provide that good first layer of defense. Maybe there’s a WAF in place.

Maybe they’re handling authentication and token creation and stuff like that. So those do have some like triad and true security measures that are in place. But once you get past that, so if I am able to find an API key, or if I’m able to. Use a service as an authenticated user, then we’re getting past that first layer.

Yeah. And the next part of it is if I know I’m testing in those environments, then maybe I need to be, I, I call it having a burner account. And so I’ll set up a couple different accounts and use different IP addresses because as soon as one is blocked and the IP address is blocked, then I know, okay, that security control is functioning and in place.

Is there a way I can bypass that? or not set it off in the first. And then using the, the next account down the road to, and at the other IP address to be a bit more careful and check things that typically require well formed requests, like authorization. So can I use the [00:27:00] API as an end user normally would, and then transition to finding other users’ resources and then can I access.

Right.

Ashish Rajan: And okay. So to your point then, if there are no differences between the cloud hosted one and regular one, cuz I think where my curiosity with that question is also because we have a field called cloud security researchers, that’s kind of, you know, opening up and a lot of them are looking at all these services that are provided by say cloud service provider could be storage, compute , whatever my thinking over there.

There’s a bit of API security testing involved in that kind of thing. Like, if you go to, I don’t know, like Facebook and look at or to your example, what you said Twitter, before you go on Twitter, you try and load your wall. I think that’s what it’s called or feed whatever mm-hmm . So it’s making a bunch of API calls, as you mentioned now, if you were to check the API for whether they are doing authorization app appropriately or.

I think cause a lot of people are trying to, I imagine that is a legit way of doing a research. As long as you don’t manipulate it, just [00:28:00] let, let Twitter know that you found something. I imagine.

Corey Ball: Yeah, no. I stick to only testing out clients that I have acknowledgement from and, and approval from which of course a lot of the cloud providers actually have blanket, statements .

For that. So yeah, first I’m making sure that I’m authorized before testing anyone. Twitter is actually a good example. So if we’re talking about the feed what you post on there is public information. So it really doesn’t matter if I can access that. Oh, I mean, it’s intended use that. I can access that.

Yeah. Your private message is on the other hand, that would be an area that would be worth more attention in testing. And then on the broken function level author, I shouldn’t be able to manipulate your request. So I shouldn’t be able to delete anything you post and so on and so forth.

Ashish Rajan: Oh, oh yeah.

Actually that’s a good one because cuz if you can pretend to be me online, I guess that’s probably, yeah. I mean that’s why authorization breaking in, right. Because you’re authenticated, but you’re messaging on my behalf I guess. Exactly. Yeah. Oh, okay. That’s that’s a good one, man. It actually cause you mentioned rest API as [00:29:00] well.

There’s another name that keeps coming up is GraphQL APIs. What’s what’s the difference between the. .

Corey Ball: Yeah. So rest API is a series of constraints that are almost like agreed upon in order to have that interactivity between different applications, GraphQL. So graph query language it’s a method of requesting that same data.

And so typically GraphQL hits a single endpoint. So you’d have. Cloud security podcast slash GraphQL, and that’s where all the GraphQL requests take place. But what you’re doing is instead. Querying and requesting to different paths in a URL , you’re requesting that single URL path to GraphQL, and then you’re forming a query in the post body.

One of the major differences is you can request exactly what you’re looking for. So in restful API, typically, if I were to request my user account. I would get [00:30:00] everything about my user account, username, email, phone number, so on and so forth. But in a GraphQL setting, you can specifically request the information that you’re looking for.

So I just wanted my email. Then you can specify you know, user Corey. And then email is what you’re looking for. And then that’s all the data that you would get back. And I actually just teamed up with Nick Aleks and Dolev Farhi. I was the technical editor on their book. That’s coming out with no starch, press called Blackhat GraphQL

and so that that’s all about pen testing, GraphQL in hacking APIs. I dedicated one chapter to it. They dedicate a whole book to it and really good stuff. Oh, it’s such

Ashish Rajan: a big space that you can hold, dedicate a whole book.

Corey Ball: Definitely. Yeah, because the the way you’re requesting and the way you’re testing can differ quite a bit because in a rest situation, when I’m performing an authorization check I am requesting the full path.

I have to find the resource ID that’s related to user be account and. [00:31:00] Make the request from there in GraphQL setting, you’re having to form these queries to a single URL and different, different technologies are involved on the back end. And it’s if you look at them side by side, they’re actually quite a bit different in how you work with them, different tools and everything too.

Ashish Rajan: Right? Because I imagine the blue team folks who are listening to this going. Is there an easy way to identify if our APIs are using rest or GraphQL or is that just basically you need a tool or something, or instead of just, I mean, I can just go on and ask a team as well, but is there an easy way to identify without asking someone?

Corey Ball: Yeah, I specific to what I was just saying, if. If your users, or if your APIs are functioning by making a series of different requests, using different HTTP methods. So we’re having git, put post delete and it’s to various different URL paths. Then you’re likely on the API side where you’re dealing with content.

That’s either in JSON or XML, if [00:32:00] you have an, a single endpoint and queries are being built. To gather data that way, then you’re likely on the graph scale side.

Ashish Rajan: Oh, right. Okay. That and would a WAF work against both of them?

Corey Ball: Yeah. WAF still should have some success with those because If the WAF is catching the request, then it should still be able to scan through the content of that and detect certain things.

You know, it’s detecting maybe the WAF in the gateway are detecting that the token is in place, that you’re only making so many requests and so on and so forth. And then the content of those requests would be really important because. In a GraphQL situation, you can request a ton of data in a single request.

Whereas in a restful situation, you’re gonna have to make a series of requests instead of just single one. Ah,

Ashish Rajan: yeah. Okay. Yeah. Fair enough. And that would be, cuz I think some people may even try and put a limit to the amount of data that’s sent back as well. And like if is designed to send a lot of data, you may [00:33:00] misunderstand like, I mean, can you even look into the data is with monitor.

Corey Ball: With monitor. So as long as you are decrypting it, which is happening at some point, if you’re using HTTPS, then you should be able to decrypt , the request and then go through it from that point.

Ashish Rajan: Oh, well, people should definitely look at that book now. I think it’s not well, depending on how, I mean, I imagine is there like a equal split between rest and GraphQL or is basically just.

Corey Ball: I mean, what you’ve seen from what I’ve seen. Yeah. Rest APIs are still the majority of what’s being used out there. GraphQL is definitely exploding in popularity. And it’s adopted by a lot of the big. Companies that are out there so that it makes it attractive to other developers in situations and maybe deployed in their situations.

And it’s just

Ashish Rajan: because you can send a lot more data. Is that why it makes it attractive or

Corey Ball: I, I think the thing that makes it attractive is you can specify exactly what you need to get. So from a developers perspective, if I need to get your user account information [00:34:00] for my service over here, and that’s a valid request, then maybe I just need your email.

So in a restful API, I’m gonna get everything in and I’m gonna have to filter that information down to what I need. Whereas in GraphQL API, I could request just your email or just all the users’ emails for whatever my services.

Ashish Rajan: Oh, right. That kind of is a good one because I just got a question here from Kennedy toura and his question is, does it make easier to pentest by consuming application documentation?

Like a swagger file.

Corey Ball: So much easier yeah. So if we’re taking a look at an API from the start from a pen test perspective, if I’m working with a client and it’s not a completely a black box situation where I’m going in blind, then we’re working with them to make sure they have API documentation in place, because that is gonna make a really big difference.

If I have to reverse engineer their API and figure out all the endpoints, the variety of ways I can make [00:35:00] requests and the parameters involved, that’s gonna take a while to build out. For the most part, if we’re talking about public APIs, they’re meant to be consumed by end users. So oftentimes there is documentation available , for developers to use.

And you can go through that. If they have a postman collection . Or if they have open API or a swagger file, then the great thing is that is something that you can import into postman and essentially from an attacker’s perspective or a tester’s perspective, either one then you have your scope built out.

So if we’re thinking about it in web application, , I don’t have to, you know, find all the secret buttons and, and stuff like that. Of course, I’ll still search for those, but essentially you have all the functionality in one place just like in a graphical interface. Interesting.

Ashish Rajan: And thank for the question as well.

Kennedy hope that answered. And I think while we were given the answer, I just reminded myself of something that I had seen in the past where sometimes the lowest hanging fruit from an API security best practice. Also just knowing what [00:36:00] APIs should be public and which ones should be private. I cause I think as a pentester, you would not know, but as a business we would, and at that point you’re going, oh, why is that public?

Have you had those situations?

Corey Ball: Yeah, definitely. And. That I think that’s one of the first thing that, that comes up. If maybe an API provider doesn’t have authentication in place. If there’s no authentication in place, then you really need to make sure that all of the requests and functionality.

Are only dealing with public information. There’s no nothing sensitive or nothing that can be done to an environment that would expose sensitive information.

Ashish Rajan: Is there an easy way? I mean, I, I guess obviously you would not know which what should be private or what should be public, but is there an easy way for people to know if there is no swagger file?

And is there an easy way for people to know what some, what are some of the API calls that can be. That can be made. So like, I’m assuming you mentioned postman earlier, you can just, well point the API and point into postman, but can it do something like a port, like a B suite [00:37:00] where it just goes and looks at all the APIs that are available?

Corey Ball: Yeah. So in on the burb suite side of things, it would be crawling for that

Ashish Rajan: information. So you can’t do that, like, like look at API calls . Yeah. There’s,

Corey Ball: there’s a crawling side, but. Let let’s say those API requests required authorization, then you have to make sure that you’re authorized before you begin that crawl.

And even in that situation, you know, maybe making so many bad requests is gonna get you blocked by a WAF or something like that. So , you’re gonna miss out on a lot of those. Another way of doing. Is actually in the apisecu course that I mentioned is free. I talk about reverse engineering APIs in there, and there’s a couple different methods.

One, if you’re just using a web application and browser, you can proxy all the traffic and have it go through postman, and then you can pull out the API requests from there. So if you find out that. Maybe the web application is using the target name.com/api/v1. And that’s where a lot of those backend requests are coming from.[00:38:00]

Then you can filter that out in postman and build out your own collection. There’s also another really cool tool called man in the middle proxy to swagger. Right. And essentially. You can proxy all the traffic of the web app specify the URL and build out your own swagger file, which is awesome.

Ashish Rajan: That’s pretty awesome. , cause a lot of people who might be listening in may have been penstesters or have that curiosity, mind as well. So I’m sure they’ll find that information quite valuable. This is pretty awesome, man. I think I kind of got to learn quite a bit about API security space as.

And I’ll definitely recommend people check out your book. I’ll leave a link for the for the thing as well. Well, I mean, I guess this is kind of like the the technical part covered and I think I’m, I’m sure people can’t walked away with a lot of sec with lot of security, best practices around the space of at least making sure you know, what your APIs are ex.

Suppose as well, that is probably adding in there, low hanging fruit for people who may not be aware where to start. . Awesome, man, dude, thanks so much for sharing all this and thank you for spending the time with us as well. I think. The security best practices, and almost knowing how a pen tester would approach API security is [00:39:00] definitely quite beneficial. So thank you so much for sharing that, man.

I really appreciate this. So where can people find you on the internet of the world? If they have follow up questions?

Corey Ball: Yeah, I’m happy hacker over on Twitter. H API underscore a hacker and they can follow me, find me there. And then over on LinkedIn you just search my name and I’ll connect with you.

Ashish Rajan: Awesome. And I’ll leave those links in the show notes as, so people can actually connect with you as well. But thank you so much for this and, and for everyone else, I’ll see you later in the week with another episode of modern security stack what do they look like? So thank you, Corey, and thank you everyone for joining as well.

See you. Thanks

Corey Ball: so much for having me on. Thank you.