[0:00]Hey everyone, welcome to this video in the Finding Your First Bug series. Today we're going to be talking about finding bugs using APIs. Now, I think APIs are great first bug materials, because there's so many different endpoints, developers tend to be a bit lazy when they develop them. Um, and they're full of bugs. And we're going to have a good chat about the types of bugs we can find. We're going to start with to ask questions like what is an API?
[0:27]Uh, what do they look like? How to spot them? Then we're going to talk about more about the hacking, how to enumerate APIs, find new API endpoints that might be hidden. Then we'll talk about the types of bugs you find in APIs, whether that's idles, information disclosures, all kinds. We're going to chat all about them. So, I hope you enjoy this episode. Let's get started with what is an API?
[0:47]So API stands for application programming interface, which actually doesn't tell you an awful lot about what an API is. It's, uh, it's quite, it's, it's a very obscure, it's like Idol, right? Um, so an API is basically a computer-friendly method of interaction with a data source or backend logic.
[1:10]So an API kind of sits between your database and your backend logic, um, and allows kind of a mobile app and a web app to use the same, um, source of data to do, to do things, so they don't have to write that specifically for the web app or specifically for the mobile app.
[1:27]Um, and they use both mobile and web. You tend to find them more common in mobile apps. And that's just because in web apps, often the API is not implemented the same way. Um, and it means that developers can be lazy. They don't need to write a special mobile app which has all of the functionality. They can just call this API, which can deal with the same backend functionality the web app does.
[1:50]So you hire, say, you know, two API developers, one mobile app developer, one web app developer, rather than, you know, four mobile, four web. So it saves them money overall. Um, so what does an API actually look like? So API's often use plain text. Uh, commonly this is JSON or XML. JSON is far, far more common, uh, nowadays.
[2:12]Um, and we'll have a chat about JSON in a minute. Um, and they return data directly from the database or some backend logic. So they tend to sit, you'll ask for some information, and it'll send you back a JSON file with the information in it.
[2:27]Um, so in this case, this first case up here, we have an endpoint called employee one, which returns to us the data of the first, the employee with the ID one here. That's our ID. And this is the resource. So in this case, we have, uh, the employee and get us the first employee in the data set.
[2:56]Which returns this here. So this is a representation of our database. We have, you know, the employee's name here. We then have items in an array, uh, and then we have something called table. So here, what this is saying is the ID of one, this is the data that comes back, right? So this is employee one.
[3:19]Now, this can actually aggregate from other data sets, you know, in this case, we return the database record employee and related records. So these items here are actually the records that relate to the employee. It might be items they have, it might be items that they use. Doesn't really matter. So we're actually calling from these two different databases.
[3:45]Um, so this is an example of a RESTful API. Don't worry, we'll go over what that means in a bit. And this one here, this is GraphQL. So here, we have a bit different. We, we have this idea of a query, but that's fine. We'll explain that in a bit.
[4:02]Um, and we're asking for a repository owner where the login is Apollo stack, repository where the name is Apollo client, and then we're asking for this data back from it. So you can kind of see that we have, uh, the return is data, repository owner, so this one here, then repository, which is a related data set, and then we have our name, description, and then stargazers.
[4:26]So here what we're asking for and this is what we're returning. So this is all written in JSON. Um, so let's have a chat about what JSON is. So, JSON is a way to represent data in a text format. It starts with a curly brace and ends with one. JSON contains objects which are denoted with curly braces, and arrays/lists which are enclosed with square braces.
[4:50]So in this example, we have a curly brace here, which means we're starting a menu object. These are key-value pairs. So the name is menu and the value is curly brace. We then have a more traditional kind of strings being set. And then over here we have our array where you can spot them with that there.
[5:13]Um, so if we want to access that, if we're thinking about, you know, array notation, we're looking at kind of menu here, then we're looking at, okay, the pop-up. So you can kind of see how this would be really easy for a computer to read. And we have menu item, etc. So that would be our our array here.
[5:35]Um, so it can be, you can kind of see how useful this is for a computer where you can access it in the same way you can access other pieces of code. Um, and it's really important to become familiar with JSON. You don't have to be an expert at it. You don't have to be amazing at it. It just helps to take the time to become more familiar with it. Um, but as you hack, you will become more familiar.
[5:54]So let's have a chat about how to find APIs. So they exist in a range of web or mobile apps. There's not specific, you know, type of app that it's more common in. There's not more common in web versus mobile. They exist in this pretty broad range. Um, so you can keep an eye out specifically, if you're doing web stuff, a web app which also has a mobile app.
[6:17]Um, because a lot of time programmers will join those two functionalities together so they have to write it once. A web app with a lot of complex front-end activity. Um, if they use a lot of JavaScript to run their front end, what you might find is they use an API to handle their backend calls, um, so it feels a bit more responsive, and they don't have to load the page multiple times.
[6:33]Because in the web, once the page loads, that's when code is run. However, with JavaScript, you can have a page run in the background, which would be our API. Um, almost all mobile apps use an API of some description, because it's easier to deal with. It's less time to download, there's less logic in there, offloading that all to, um, a API is a lot easier.
[6:55]Um, a web app that takes a long, long time to load can have an API, because it might be calling multiple different resources from multiple different servers. Um, a web app with developer documentation. Now I'll have a chat about this in a bit, but if you see the kind of, you know, Twitter has a way you can create your own apps that use Twitter, and they they promote their API, and that let developers use it, that can be a good sign that something is using an API.
[7:19]Um, so what are the types, types of API? Uh, there's SOAP, which is way less common nowadays. It uses XML. It has like a little header and a body, it's got an envelope style, um, it's really old. You won't find it very often, okay? You're going to find it very, very rarely, maybe on like a really old website.
[7:41]Um, so we're not going to really talk about SOAP. We're going to talk about the newcomers on the scene. First there's RESTful, um, and we'll chat about what RESTful means, but, um, it's the most common API you'll see. Um, it follows a very defined structure, so it's quite easy to spot, and it uses JSON for the returned data.
[8:01]Um, and then we have GraphQL. Now GraphQL might be really good if you to learn if you're a beginner, because GraphQL is only just becoming more popular. There's still people who write GraphQL APIs who don't actually know how to implement them correctly. So maybe if you learn GraphQL, you're looking at really being in quite a small group of hackers, and that'll really allow you to, um,
[8:24]um, work in quite a small area and find bugs that maybe would already be kept, like would be caught quite easily by big hackers who who are very good at hacking, but actually, they exist on the GraphQL endpoint. Maybe they don't know GraphQL. Um, and it's really a newcomer on the scene. It uses a custom query language. Um, and we'll see a bit about that in a bit.
[8:44]And a single endpoint powers all of the API. So we'll see the difference between RESTful and GraphQL in a bit when we talk about what they look like. Um, other APIs, sometimes you'll see standalone JSON calls, that you'll just see like a random endpoint that gets sent some JSON. That's worth investigating, even if it's not, you know, these kind of defined ones.
[9:07]Often times, you know, you're not supposed to have stay in RESTful applications. So, um, you can maybe see those standalone calls. Sometimes you'll see just a random call. Sometimes it'll be sending some JSON in the body of the request, but it's worth keeping an eye out. Um, web sockets are also used as APIs. Um, I'm going to make another video on what web sockets are and how people hack them.
[9:28]Um, because that's also becoming, you know, more popular as we start to get these more interactive websites with JavaScript, and people are looking at these different technologies for power of their APIs. Um, so let's chat about RESTful. So RESTful APIs are really easy to spot. They have this kind of defined structure, which relates to CRUD functionality.
[9:46]So you can see in my little graphic here, um, this is our defined structure. Uh, so here we have a create where we're using post and then we have posts as our as our resource. We have a read, we have an update. Now, for RESTful, they can have several different, uh, update and delete, um, formats.
[10:06]And that's just because some people don't, um, implement the put or the delete HTTP header. Um, so we have our get and post. We can also have put and delete. Sometimes developers don't implement put or delete, so sometimes these ones are replaced with these other ones up here. Um, so, it's really easy to predict new endpoints simply by knowing an application.
[10:30]So if we take YouTube, for example, we might see something like get video and then an ID, like one, right? So you can kind of assume that deleting a video must also exist. So that's, that can give you your delete endpoint. You can then assume that, okay, if video exists, maybe comment exists as well, right?
[11:00]Because you can kind of have, um, your videos and you can kind of have your comments and you know, it's, you know, if you can kind of start to predict the structure of what a RESTful API looks like, you could start to also predict how, um, how other resources might be there or, um, what other methods might be there.
[11:21]Um, they're really widely used, but some endpoints might be custom, you know, sometimes you'll get delete, or sometimes you'll get a post on a delete, um, uh, endpoint. Uh, so it's useful to kind of, uh, uh, spot these if you can, but just noticing that it's an API can be very powerful in terms of hacking it.
[11:42]Um, this is just easy ways to spot it. So they usually return JSON. It's very rare you'll see anything return XML nowadays. Um, and you can get a Burp plugin to automatically visualize JSON called JSON Beautifier. Highly recommend it. Super easy for hacking APIs when you can sort of see everything structured correctly.
[11:58]Um, so let's talk about GraphQL. So GraphQL is much more difficult to spot, because you tend to have an endpoint like GQL question mark, Q equals or GraphQL question mark, uh, Q equals or G Q equals, you know, there's loads of ways to, uh, uh, represent something that's a GraphQL endpoint, and there isn't really a standard as of yet.
[12:20]I've seen all of these. And an easy way to spot these is try and find a reference to a query or a mutation. Um, so over here we have the same CRUD functionality here. But this is always on the same endpoint of this GraphQL Q. You just have this mutation, create post query, put post ID, update post, and delete post.
[12:46]Um, it has a major advantage to hackers, though. It's super easy to enumerate. I'm going to talk about that in a bit, but it's really good to find idols in this, because it's very easy. Um, these also return JSON, but it kind of looks weird in the structure when compared to the RESTful APIs. Um, however, you'll probably need some practice forming queries.
[13:05]Um, and I think the best way to get this is the Hacker 101 GraphQL CTF levels. Um, they're really good. They're really good for letting you learn how GraphQL works, and as long as you get your sort of head around it, it can be really useful to learn how to write these mutations and queries. Um, so those are the two endpoints, the two different types of APIs we're going to look at.
[13:28]And that's simply because, one, RESTful APIs are so common, and GraphQL APIs are so new that I think they're great for finding first bugs. There's tons of different other types, though. Um, so let's have a chat about API documentation. So sometimes APIs have their own documentation for developers to use, and that's basically because they want developers to be creating apps for their products, right?
[13:54]So this is Twitter's here. We can kind of see we've got some references to, um, off over here. And you can see we've got get and we've got post. We've also got something to do with lists. So here you can kind of see we've got a post create list create and a post list destroy instead of our, uh, um, put and, um, delete functions.
[14:18]So this is sort of Twitter's own developer documentation. So they can be a fantastic tool for recon, because they describe in detail how to interact with the API, um, whether that's, you know, what you should be sending it, what you should be expecting back, what each parameter means, and what each sort of returned information means. So it's worth looking for, you know, target developer docs or target API.
[14:40]Um, sometimes you can find answers on tutorials designed for developers or on Stack Overflow. That can be a really, another really useful way to find, um, API information. Um, okay, so let's get the bit we want to talk about. Let's talk about testing APIs. So what are the bugs and how do I test for them?
[14:58]So before we do any bug hunting, we've got to start enumerating our APIs. Um, so enumerating APIs means finding more information about APIs. Um, so it's very important for API testing. It allows you to be sure you know everything inside the API. Our goal is to use our knowledge on how endpoints are constructed to find more resources.
[15:18]For example, if users one edit exists, does also orders one edit exist? And it works a bit differently for RESTful and GraphQL, and I'll chat about that now. Um, so RESTful APIs. So as we discussed, RESTful APIs, the APIs that have those distinct structures associated with them, and talk about resources.
[15:42]Um, so that you can imagine that'd be quite challenging to enumerate, because we need to guess the resource names. Um, you can look at common resource names, um, using a list of common RESTful endpoints or a word list. This is one I really like in FuzzDB, because I think there's quite a lot of nice ones there, especially account accounts, um, company domain, um, these can be really useful.
[16:06]I also have a custom list of RESTful API endpoints, um, and you can find, um, a bunch of different word lists. Sometimes you can find a more tailored word list. Sometimes someone who works on the target, like a big one, like Uber, might might show all of their API endpoints they've found so you can test that on new domains.
[16:26]Um, so that's one that I'd have to just have these these common resource names. Another method is to use custom ones. The more you learn about how an app works, the more you can kind of guess what it might have. Like, does the API power a forum? Maybe you're looking at posts, and reply, and comment, or you know, maybe you're looking at, um, a social network. Maybe you also have likes in there.
[16:49]Um, maybe if you're looking at a cryptocurrency, you have orders, or, um, currency, or wallet. You know, you can kind of get, you can kind of work out what resources might be there by looking at the kind of web app. And especially if you see, um, kind of discussions about what might be resources, you usually people talking about your wallet is where all of your money is kept.
[17:11]You might say, okay, wallet and money really sort of stand out as those that could be resources. Um, and really for both, the kind of method is the same. You send a valid RESTful endpoint to Intruder, so you just right click, send to Intruder, import your word list, and replace the resource name, I, users one edit, and replace user with, um, the kind of squiggly lines.
[17:37]Um, the section part for, uh, Intruder, and that'll let you kind of, um, enumerate through all of these different API endpoints and see if one exists. And you're basically looking, you know, what the valid responses are. If you're working with a really big word list, you can, um, uh, sort by the length of the response.
[18:00]So it's really useful then to have like a get response, for example, where you're going to, it's going to return back to you information about it. Um, so let's talk about enumerating GraphQL. Enumerating GraphQL is much easier. So there's something called an introspection query. Um, and you can find that on, um, payload all the things.
[18:21]If you look up GraphQL introspection. And it'll return every query that can be run on the database and what parameters these queries need to work. So, basically, it gives you this is a visualization using GraphQL Voyager. But you can see here that each one of these is a resource, and these are every query you can run, and it tells you, you know, string what it needs to input, and it tells you what it returns.
[18:43]So this is really useful for basically telling us everything an API can do, right? Um, and it allows you to see this visual representation, which is really useful. And what you can do when you start to enumerate these is you can just get stuff back, right? You can just see that and go, okay, um, I can make a query that says get user, and get user also returns a bunch of information, you know, is that an idle?
[19:10]And we'll talk about kind of bugs in APIs in a minute. But GraphQL is much easier to enumerate. Um, so one thing I wanted to talk about just before we talk about the bugs is about API versioning. Now, often APIs have several different versions running at once, and in later versions, bugs will get fixed.
[19:28]However, in the older API, the bugs may still exist, right? The older API may still be active and it still has the same bugs. And sometimes these older versions get deleted, but sometimes they are still accessible but not used. So maybe if you see an endpoint like API version three users one edit, you should check for version one.
[20:01]Um, and you know, there have been bugs where one of the bypasses just is, for one, like idle is just to use an older version of the API, they still left, um, unsecured. So that can be a really useful way to kind of, if you're realizing you can't find something, it might be worth checking and seeing if you can see it at an earlier version.
[20:22]Um, right, let's get into the meat then. What bugs are actually found in APIs? So, number one, information disclosure. APIs can sometimes return more information than they need to, um, and sometimes this information really shouldn't be returned. Um, authorization issues. Uh, APIs often sit behind some logic.
[20:44]That means although the web app might require some authorization, the API does not. Now this is related to an idle, but you can see this. And I'll discuss it a little bit later to talk about how people bypass authorization using the API, and there's some really interesting examples on it. Uh, three, business logic.
[21:01]Sometimes APIs have some validation, do not have the same validation as the client. You know, maybe in the client, they're testing for a negative quantity in orders, but on the API, they're not. So that can be a really easy business logic error to find. Um, and idols. So, uh, idols, you know, APIs are great sources of idols.
[21:20]Resources can be accessed directly via the API, even if they shouldn't. So you might be able to edit a resource via the API, even though you really shouldn't be able to do that. Um, because you're not logged in correctly, or, um, they just haven't put that if statement in there to check the permission level. Uh, then you have XSS and CSRF. So APIs can be great to proving more impact with bugs like XSS.
[21:44]So if you find a CSRF bug, and we'll talk more about that, and there's a video coming very soon on CSRF, um, where an API does not ask for some random token, um, which is our CSRF. You can use these to impact a user's account via the API. The standard gold standard one is by putting a stored XSS on a web page, um, and requesting to change the user's email address.
[22:13]So every person that accesses that web page gets their email address changed via the CSRF, which is a complete account takeover. Um, so I've bolded the ones here that I think are the best ones for beginners to look out for. Um, and kind of in order, really, information disclosure, business logic, and then idles are all worth looking at.
[22:32]The other two are far more advanced techniques that require a little bit more, um, experience. I'm still going to talk about them and kind of expose you to them, but I don't expect you'll find them like super easily, right? So don't worry too much if these are a bit above your level.
[22:50]Um, so let's first talk about information disclosure and how to test for it. So for information disclosure, we are looking for an API that returns back too much info. Sometimes an API might return a ton of info but never display it, or only display some of it. So, um, here we've got an example report that where the, um, uh, RESTful API is just restricted for the general public.
[23:20]However, it's also accessible somewhere else. So you can kind of see how the API is then disclosing information, or, although it might be restricted on the client side, however, it's still accessible via the API and still leaking that information. And this is a really easy to test. Sometimes you just call the API.
[23:37]Um, sometimes you might find hidden endpoints by doing some enumeration, and then you just have to sit and make a judgment call. You know, is it a security risk? Um, could it help a larger attack? You know, if you can enumerate everyone's email addresses, that could be great for having a kind of attack on, um, the, uh, website's users via phishing, for example.
[24:00]Um, does the target really want this public? I mean, maybe it has a bunch of order information, it doesn't have someone's credit card info, but you can see, you know, what everyone's ordered, what their username is, that might be something the target might want to know about. Um, and does it return an awful large amount of data?
[24:17]Like anything that returns a large amount of data should be setting off your little alarm bells in your head, because you should be thinking, why is it returning that? Does the company really want that public? Um, so this is a really easy one to test, because really what we're doing is testing the API and just poking it and prodding it and seeing what comes out.
[24:37]Um, sometimes it's good to look and see, um, if you can kind of, um, work like, work with it. Like if you can kind of find, okay, this is an admin only endpoint, but actually, it has been secured properly, and stuff like that. Which is really getting the kind of idle stuff, but information disclosure, you know, an idle is only a security risk if you're impacting somebody.
[25:02]If you're looking for information disclosure, maybe it's more on that end. Um, so super easy bug to try and find, because it's very straightforward, very easy. Um, let's talk about something a bit harder now. Let's talk about authorization issues. So, authorization issues are really difficult to test for unless you kind of know what you're looking for. And our kind of aim is to use the API to bypass an authorization process.
[25:27]Um, so, you know, getting past automatically generating, say, a token to log in, right? Automatically generating OAuth tokens. That would be what we're looking at here. Um, so this example here uses a cross-domain, um, via the API to bypass the REST OAuth authorization flow. So what they're doing here is they've basically got this authorization flow that's like log in, username and password, you create a token.
[25:51]And they've found out a way to bypass that using the API, um, to then generate authorization tokens. So, you can kind of see without really knowing a lot about hacking, this can be quite difficult. Um, however, if you did want to test for this, you should understand the authorization process. You know, what API is being called, what tokens are being generated, what tokens do you need?
[26:20]What endpoints need them? So, you're really there asking, what does the authorization issue look like? And you may want to sit down with like a piece of paper and a pen and start drawing boxes and kind of drawing arrows between, okay, this is how this works. Um, then you really want to ask yourself, okay, how can I use the API to generate tokens without the need to log in?
[26:48]Can you use another API endpoint to access the functionality without needing a token? Which is a slightly easier way to find an authorization issue. Um, but what you really want to do is find endpoints that generate tokens here. Um, and then the question is, how can I use this to generate kind of tokens that I shouldn't have access to, right?
[27:07]Um, I really recommend if you're interested in this, looking at some of the disclosed reports that are related to, um, the authorization flow and OAuth flow, because I think it'll really help you to understand this if you're interested. Um, so back to something that I think is a lot easier, business logic errors. So they're security issues that abuse the normal functionality of an API to cause security risks.
[27:30]And they're very common in APIs, as often the validation is only on the client side. Um, so I, I've made a whole video on business logic errors, if you want to learn more about what they are and how they work. Um, so in this, in this, uh, uh, report, here all they've done is change the quantity to zero, um, and then you'll get an item for free, which is the standard business logic error.
[28:12]Uh, so I, this is really useful if you're dealing with something that takes a lot of orders, something that has some kind of payment system associated with it, some kind of shopping cart, very useful. Um, so how do you test for them? My standard ones, if you see a number, make it really large. If you see a number, make it negative.
[28:30]Some other people recommend, you know, if you see true or false, change it. So if it's true, make it false. If it's false, make it true. And then try to skip over steps. You know, maybe the API will let you transform the order beforehand. So when you're looking at that, you're maybe saying, okay, it hits the API endpoint, um, make order, then it hits the take payment, and it says payment accepted.
[28:53]Could you go from, um, make order to payment accepted without hitting that, that other make payment endpoint? That's, that something APIs might be really good if they're not checking their logic correctly. So that's always worth looking for when you're dealing with APIs which have either complex flows of data.
[29:10]Same as the authorization flow, really. But also, um, things that have like quantities are really useful. So my favorite, testing for IDOLs. So IDOLs are by far the easiest and most common bugs in APIs. You can see my video on IDOLs for more information. Um, but to be, to be kind of brief, you want to use Burp Repeater to repeat every request to each endpoint.
[29:36]Remove your cookies. Does it still work? If yes, idol. Replace your cookies with a lower permission user account's cookies. Does it still work? Now, an easy way to do that is to just log in, copy the cookies, put it into something like notepad, and write down which cookie it is. And then, just repeat it. You can also use the replace functionality and replace a, um,
[30:00]API with, or a cookie with something else. So you can use something like authorize. The example on the other side is, uh, from Twitter. And here we just have an API that makes a request. And they just removed their cookies. And they just have the CSRF token without any of the other cookies. So, this is an example of an idol. Super useful to do APIs.
[30:22]Very common in APIs. I highly recommend looking for IDOLs in all APIs. It can be a bit difficult to test for them. And I'll show you an example in a minute of what it might look like to test for test APIs. But, uh, it can be quite like time consuming, but so worth it, because you that five minutes you spend looking at each endpoint is the might be the difference between finding an API an IDOL and not finding an IDOL in an API.
[30:51]Um, so, testing for XSS and CSRF. So that's cross-site scripting and cross-site request forgery. Um, so a common defense against cross-site scripting attacks is filtering. I'm sure you've all seen when your, um, thing doesn't work, like your, uh, API, XSS payload doesn't work, because they're stripping out the tags, for example.
[31:18]So, these can only be implemented on the client side. So, some people might just say, okay, well, I'll put some client-side bugs that, or filter that says, if contains API endpoint, remove. However, if you can find a request to the API, which takes some input and reflects it, you might be able to send the XSS payload directly to the API, bypassing the client.
[31:40]So an example is on this, um, Shopify example. Um, here what the person is doing is they are sending the, uh, XSS payload to the API endpoint rather than sending it to, um, putting it in an actual comment box, because there's no filtering there. Um, so that's a super easy way to find XSS in the wild, um, even though they're still quite difficult to find.
[32:10]I wouldn't suggest them for first bugs. This is a way to find them. Um, and CSRF is also really common in APIs. So, this allows an attacker to from actions on a victim's account by abusing the fact that they might have clicked the box that says keep me logged in. So if you are, press the box that says keep me logged in, you still have your, um, cookies on.
[32:33]If you send someone a link to a web page where they're already logged in, um, you can kind of abuse that to do actions to their account. However, as I discussed, you could also join these two bugs together. You can have a page that has an XSS payload, which calls your, uh, CSRF, um, uh, endpoint, um, meaning that you can kind of do like a full account, account takeover with just these two bugs by changing someone's email address, for example, and then just requesting their password.
[33:04]And I'll talk more about CSRF in a future video, and talk more about what it is, and how to defend against it, and how you can tell whether or not something's, uh, vulnerable to CSRF. So, a good thing for APIs is just find an endpoint which does not have or does not need a CSRF token. Um, and the CSRF token is just a, um, randomly generated token, which is checked on the website, which just checks that you actually clicked the button to initiate an action, and you're not like randomly pulling in an API.
[33:36]Um, and especially keep an eye out for ones that edit details, not so much when ones that denote details, but especially ones that edit details, um, tend to be vulnerable to CSRF. Um, how about other bugs to keep an eye out for? You know, APIs aren't just vulnerable to these bugs. Keep an eye out for SQL injection. Since APIs often access the database, sometimes you can find a nice SQL injection. Race conditions.
[33:53]They can be fiddly to get set up, but APIs can be excellent sources of race conditions. Memory leaks. Sometimes you can use special characters like null bytes to get an API to spit out memory. So let's talk about SQL injection. SQL injection is quite rare. However, since APIs often access the database directly, sometimes you can find a nice SQL injection. It's rare, but it happens, right?
[34:14]And it, like there's a few things on how to take a GraphQL endpoint to injection to SQL injections, um, on the payload all the things. I'm going to leave that link in the description. Um, yeah, so that's really useful. Race conditions. Um, it can be really fiddly to get set up.
[34:31]I do plan on making a video about how to use, um, race condition, how to find race conditions and, um, soon with some like practical demonstrations of how to write the code to do them. Um, and they can get fiddly to set up, but once you can, APIs can be excellent sources of race conditions, because often they're located away from someone's device.
[34:57]If you're using, uh, uh, an application like a mobile app, they might account for some delay, and they're not expecting it. So you can send multiple requests at once. You can actually do some really interesting stuff. It's great for doing like payments where you can send maybe three payments, but it all works. Like it all sends the money, um, even if you only have enough to do one.
[35:18]Um, and then memory leaks. So sometimes you can use special characters like null bytes to get an API to spit out random memories. Um, once again, more advanced, uh, uh, type of bug, but still really useful, um, when looking at APIs and what you should do. So I wanted to briefly talk about taking notes.
[35:39]Um, so when dealing with APIs, note taking is extremely important. Here I've made like a, um, sort of, uh, sample, um, spreadsheet of what I use to find API endpoints and what I'm really doing here is I've got, okay, can I remove the cookie to get an IDOL?
[35:59]Can I, I'm have a low privilege IDOL? Does it have CSRF protection? Does it have an XSS filter? Is there some business logic that's a potentially abusable? And I'm just thinking about what the impact of that could be. So here, if I've got an IDOL which is on both, but maybe it's not like a high value, um, resource. And maybe putting it as a medium, and I haven't actually finished this either. So,
[36:26]we've got a high here. I put no into everything. Oh, sorry. Yeah, it's not possible on everything. But it seems suspicious, right? So I want to come back to it and see, um, what would I, what what might be there? Um, so often you have a large amount of endpoints that must be tested one after another. And consider a spreadsheet. I like to use a spreadsheet. Um, and I came up, I really developed my spreadsheet over time.
[36:50]And it's really useful if you're testing a large application for IDOLs, because you can basically take your step one is to click all the buttons and get all of the API that's visible. Then step two is your enumeration of the API. Then step three is to basically copy all of the endpoints you have into your spreadsheet and work through them systematically. Um, and it's really dependent on how you like to work. But I really like this for kind of going through things one at a time, um, and not getting too lost in an API.
[37:23]I'm really having a plan of what to test next. Um, and yeah, I also have some comments in here as well. Um, like maybe I find a CSRF, but actually, it's not very impactful, so I'm not really considering reporting that on its own unless I can get that XSS later on. Um, to kind of abuse it more. Um, and then we also have the difficulty to generate IDs, but low privilege user, it might be okay to still report it as like a medium or a low. So,
[37:48]that's kind of how I like to take notes. People take notes in different ways. I think it's very personal how you take notes. Um, this is just if you don't know what you're doing and want something to work with, this is the way I do it. You can copy this. Um, so, well, I'm really interested in this. How do I learn more? What do I do next? Now your first option is to get comfortable with APIs. So CTFs are really great to get used to building up your familiarity with APIs.
[38:18]Um, and although I wouldn't suggest keeping on them for too long, especially something like GraphQL where you have to learn how to make queries and exploit things. Actually, using an API can be really, really helpful, right? So for GraphQL, I recommend the Hacker 101 GraphQL levels, and they actually helped me get my first GraphQL bug. I, I found my first one because I'd done those levels, and I was familiar with how to write the queries and notice when I saw a GraphQL endpoint.
[38:45]Um, so I really recommend that for learning GraphQL. For RESTful APIs, I actually recommend sitting and building an application. And I don't recommend this enough actually. I really should recommend it more. For learning how to hack, one of the most powerful things you can do is make something, like make a web app, and learn how to think like a programmer does. Because you'll see yourself make, like making mistakes, very easily, you know, like you'll be finding you're, if you try and hack your own web app, you're going to find that you're full of bugs, right?
[39:16]But knowing how to develop my thing can be really helpful. So it's not a CTF, but it will achieve the same goal of getting you more comfortable with using an API and how they work, and how they might work under the hood. And that'll really get your confidence level up. And I think that's really important when dealing with APIs is that you don't want to feel too overwhelmed by them. You want to feel like, okay, I can tackle this.
[39:35]And sometimes all you need to do that is just a little bit of practice before you jump right in. Um, so you can learn more about bug, bug, API bug hunting. Um, I actually don't recommend actually, I should probably add more of these if you want to learn more. Um, a great source of learning more or even if you're just need inspiration, you're stuck, is like reading and specifically reading either disclose reports or write-ups.
[40:01]Um, I highly recommend going to Hacker One's hacktivity and searching for API. That's why I found all the examples. Previously I put an API and then the bug class I was looking for. Um, but you can also find write-ups using medium articles, on medium, by using Google, or you can find it by looking at Twitter. Um, and here's an idea of a broken, uh, here's an example of a broken API authorization.
[40:27]Um, and they've gone into detail about how they're doing like, uh, uh, directory searching, and how they're enumerating APIs, um, finding a documentation site, you know, having this kind of idea of how this is how someone else approached a problem can be really helpful for other people to learn how to approach, uh, API bug hunting. Um, and the final suggestion, start hacking.
[40:50]If you want to start hacking, I suggest starting out with a mobile app or a large web app. Um, either whether that's something like, I know it's difficult to get an a testing environment set up, especially if you're on iOS, but Space Racoon has put out a really good blog post on how to do get started with getting Burp to read, um, from iOS.
[41:14]And if you're an Android, or if you're like platform independent, you can use an Android emulator. Jenny Motion is very good for starting out. Um, so enumerate the API as kind of basic recon. Start by asking yourself, does it have developer docs? If not, you know, what are the resources it starts to use?
[41:34]Um, what kind of resources it may use, looking at our kind of word list and what kind of word list you want to find. Um, whether that's using things like directory spoofing, um, whatever you want to do, but sort of do that enumeration of API kind of as a first step. Um, then start testing for IDOL specifically. I think IDOLs are the easiest one to find.
[41:56]The easiest ones for me to explain to you how to find, and the easiest ones to approach. Um, and it's going to help you become more familiar with APIs and how to test them and sort of get your familiarity level down. Um, and it also allows you while you're testing for for IDOLs, this is to look for information disclosure as well.
[42:17]Um, keep asking yourself if it seems appropriate, if it seems sensible. If it makes sense to what a functionality does. You know, link it back to that business logic. And honestly, sometimes normal functioning is a bug. Like sometimes functioning as intended is an unintended security risk. Right? One of my bugs is literally just been, it works normally and it shouldn't work. Um, so that's kind of my, uh,
[42:41]API testing methodology, if you like. Um, I hope you found this, this video interesting. Um, I know it's kind of long considering there's no demonstration, but I really do think APIs are such great sources of first bugs that it's so important to, um, talk about them and really discuss this more.
[43:01]Uh, so I hope you found this interesting and useful. And what I might do is I might do a Burp video talking about enumerating APIs and going into more detail about that particular recon side of things. Um, just so you guys can see something a bit more practical. I didn't want to include it in this video because it's quite long and I wanted to make sure I covered kind of the methodology stuff and getting, so you can start testing for yourself, and then you can look at my videos later. Um, so thank you very much for watching. I hope you found that very interesting, and I will see you guys next time. Have a great day.
