Hacking Your First API!

Key Takeaways

When exploring APIs, you'll soon realize that they're not that different from any other request. But as you go deeper, you'll begin to see common mistakes and weaknesses that we should be aware of. So today, we're going to look at how we can start to interact with APIs and cover the most common bugs that are found when testing them. And so if you've never tried to break into an API before, then this is a good place to start. If you enjoy the video, then don't forget to like and subscribe. and let's dive in. So, the first thing we want to do when we're looking at APIs is try and find some kind of documentation. So, this could be Swagger or it could be an endpoint that gives you the information or it could be open API documentation. Whatever it is, the more information that we have, the easier this is going to be. So, I'm just going to come into here and open up my browser. Now I've got some APIs running on port 3000 on my host machine. And if we just go to the base URL or sometimes if you just go to / API, you can find documentation or some information about the API APIs if you don't have any like wiki or getting started info. So if we just click on pretty print or if you use Firefox it's a little bit easier to read and we can see that we have this catfacts API. So this is version one and then we've got some authentication endpoints. We've got these facts endpoints. We've got the pictures and then we've got admin and then we have another set of facts endpoints which actually looks like a copy of this one except that some of these require API keys. So this is the first thing that we want to look at is does the documentation look okay? Is there anything in there that is a quick win? So an endpoint that might not be protected. For example, can we just go to get/admin users and doing basic checks to make sure that we cover any lowhanging fruit to begin with? But going through and systematically testing the APIs and making sure they are somewhat the same as what the documentation says is kind of a boring task. but pretty important and going through and making sure you understand what each endpoint does is also quite important as well. Now, if you're using something like Postman and you have a nice collection, you can just import it straight into there. And I think this makes testing a lot easier, especially if you're handling multiple API keys. You can set them as environment variables and then you can go from there. Whereas manually testing in proxies when you've got lots of different API endpoints or you're trying to string things together or maybe you've got a couple of hundred APIs that you're having to handle is a bit difficult. It can easily spiral out of control. And from what I've seen so far, I've never seen a good way to manage and organize your API endpoints within uh common proxies. So like BPS or Kaido for example. So that's where I would definitely switch over to Postman. And usually if I saw this set, I would probably just switch over and try and import the collection as well. But today we're just looking at vulnerabilities rather than the whole life cycle of breaking APIs. So let's take a look. So first up, what we want to do is try and get these into Burp Suite. So, if we've got a get request here, we can switch back to Burp Suite. And let's grab this get request, send it to repeater, and what I'm going to do actually is change the request method to post. And then let's see if we can register. So, register. So, I'm going to just try this in JSON because I'm pretty sure the API accepts JSON. username Alex password Alex and then we need to make sure that we've got the content type. though here the content type is application x dubdub form url uh encoded this probably won't work if we send this we get endpoint not found I need to put the endpoint in so orth register you can see that we got validation failed and this is because we didn't change the content type so always make sure that you check the content type when you're playing with APIs and we still get validation failed six characters long. Let's do this. And then we get an API key. So, we don't actually know how to use this. So, once again, if we had documentation, then we could just follow like the getting started or a quick start guide or something like this. But this is probably a header. So, we can just use this. And let's take a look at get API facts. So, I'm going to come back to here and try and build up this request. And then let's send this. And this is an unauthenticated endpoint. So, we don't actually need the API key. But let's see if if we do API key like this in the same format that it returns back to us. Let's see if this makes any kind of difference. And where's the content length? 20005. [Music] Same content length. So being authenticated doesn't make a difference here. Although we're not 100% sure. This could be like X API key or something like that. We're going to have to figure out how to use this endpoints as we go along. So if we come back to here, we can see that in this fact section, we can create with the API key. So let's quickly try and do this. And what I'm going to do is just come back to the post request that we had before. Copy this. And then was it slash API slash facts and then application JSON and then API key is going to be this. And let's see if it comes back with any information about it. So please provide the API key in the X API key header. All right. So it gives us some information about how to pass the API key in. There we go. And then validation failed. So we need the type field message and then uh fact text and the location needs to be in the body. So reading error messages of API gives us really useful feedback quite often on how to use the API because usually APIs are designed to be chatty and be useful to developers. And so when we're using them, often they'll give us information about how to use them. So this is really nice and something that we should always be keeping an eye on. So let's get rid of this and let's do fat underscore text and let's just say cats are the best and send this and see what happens. And then we get successfully created. So hopefully if we send all of these here, we can see that the content length is higher. So 2133 and then the most recent one has been added. So this is the one that we've created and the author Alex. So as you can see what I'd suggest is when you're starting out using some APIs. It might be a little bit boring but be curious. Try and use every single API endpoint as it's intended to be used. Understand how it works. And getting an understanding of the whole collection is really the first point for breaking APIs. Otherwise, you'll never be able to go beyond the really basic lowhanging fruit attacks if you don't understand how the target works. So, now that we have an understanding of the API endpoints themselves, we want to start looking for interesting behavior. And something that we need to always be on the lookout for with APIs is serverside request forgery. So whenever an API or any request uh for that matter takes in a URL or partial URL, we need to be testing for serverside request forgery. Elevate your cyber security expertise with TCM security certifications. Our certifications offer in-depth practical training in penetration testing and ethical hacking. With real world exam scenarios and expert guidance, you're not just gaining a certificate, you're gaining a skill set that's in high demand. Visit certifications.tcm-sack.com and take your first step towards a distinguished cyber security career. So, in this case, what we're going to do is I'm going to take a look at the pictures collection. So, here we can get all and we can get /appi slash pictures. So, if I just grab these and hit send. And notice that I need to update my API key so it's the correct one. Otherwise, we're going to run into issues later on. Luckily, this endpoint isn't protected by an API key, so that's fine. But here you can see that it returns some interesting information. So, we have one picture. There's an ID of two. And this is a test picture. The author is me because I created it previously. and the URL is here. Now, the fact that it takes on a full URL for this image is something to take a look at. So, what I'm going to do is instead of creating a new picture, I'm actually going to jump straight to the put request where we can edit a picture. And this is where the vulnerability in this set of APIs lies because what you'll often find is that common issues. So for example, injection tax, most login forms are protected against things like SQL injection. Most get requests are protected against things like serverside request forgery or they've been tested so that they have no impact. But when you start doing things like finding put requests where you can modify an image and maybe you inject some XML into that image and change it to an SVG, for example, or you change where it's supposed to live. This is where you commonly find uh overlooked vulnerabilities within the application where it's just a little bit deeper and requires a little bit more thought and logic for testing. So let's change this to a post request. So go post API pictures and I think we can just pass the ID in. So updates yeah requires the ID. So, in this case, it's ID2. And then we want JSON like this. And then what I'm going to do is I'm just going to grab this here and paste that in. So, we've got the same API key. We're all good. And let's just see whether we can update the image to begin with. So, we get endpoint not found. So, are we using API/ pictures/ ID? I made a big mistake here. I forgot to change this to put. So, we want a put request to edit because it's a REST API, not post. So, let's put that back in. So, it doesn't look like it appreciated that request and quickly looking at my host machine. Yeah, it looks like it threw an error saying input of test was an invalid URL. and nodemon has brought it back up, but looks like we're actually going to need to grab a new API key. So, I will do that very quickly and then I will come back. And this is just because we don't have the uh try catch block around the URL validation. So, bad development work on my part. All right. So, I've just grabbed another API key. And what I'm going to do here is instead of just sending a random uh string, I'm actually just going to pull up collaborator. Copy this and then do this. And then if you don't have BSE Pro or if you're running on something else, you can also use web hook. Just try not to leak sensitive information to it because you know it's a site that you don't control. So if you're leaking your client data, they probably won't be happy about it when it turns up somewhere else on the internet. And then we get picture not found, but that's because we restarted the app. So let's create a picture very quickly. All right. So I've just gone and created a picture. And where was I put? So as you can see, playing with APIs can be a little bit of a pain, especially when uh you're jumping between requests and they're kind of organized in blocks like this rather than as a nice collection. So I definitely recommend that you check out Postman. It's a really really useful tool and it's covered in our API course. So if you're interested, you can go and take a look at that. But let's try and update this. And looks like we got picture updated successfully. So once again, we didn't really need to know any of this information. We just copied and pasted it. And if we pull now, we can see that we do get the DNS and HTTP requests. And here we can see the user agents. And then we can see the response as well. And interestingly enough here we can see the response reflected back to us. And a lot of the time when we have serverside request forgery it's going to be blind SSRF which might not be as useful although can still be exploited in certain uh circumstances. But in this case having like full read or being able to see the response is really really powerful. So now that we've found and tested serverside request forgery, we need to find some kind of impact. And the most common way to do this is to look at the metadata endpoints if it's hosted in a cloud environment or to start trying to get to endpoints that we shouldn't be allowed to get to. So, if we flip back to our documentation quickly, we can see that we have these admin endpoints, and we shouldn't be able to get to these. But let's see if we can get to /admin/ users for example. And what I'm going to do is since this target is going to send the request on our behalf, instead of doing 192.1681.117 where the host is, I'm actually just going to say, hey, do localhost and then 3000. And then we want it to grab the admin users. So the request is coming from itself. And sometimes this is enough to bypass access controls. And as you can see when we do this we actually get status code 200. It accepts it and then users retrieved successfully and then we have the user uh Alex and we also have the user admin as well. So we can start interacting with the admin dashboard. And if there are any get requests so for example we can get by ID which might give us more information about an individual user. So let's do as it let's have a look to see here still only returns the same information unfortunately but still useful to know that we can get to that endpoint. Now the limitation here is that we don't have the ability to post, put, delete uh with serverside request forgery usually and so we are limited to just these two get requests. But even still being able to list all of the users within the application and seeing when they signed up is quite powerful and is a big finding. And then we can also once again like I say start to try and look at metadata endpoints or search for other endpoints or maybe search for get requests that have some impact. If you've seen the port swiggle labs for example I think you can get/ API/delete users and I've seen similar things in API collections in the past as well. So really the key to breaking into APIs is first trying to get a good understanding of how they work and how they interact with each other. Second, try and use every single API endpoint and put some meaningful data into the target application. Third, don't do what I do. Don't accidentally crash the application and then have to keep restarting it. And you know, I'm a lazy dev. I actually don't put a lot of fail safes in and I just use nodemon. So, usually when the application crashes, it reboots, but then it receds the database cuz it's running in memory. Obviously, this is going to be different to a production system or a system that is well-built or a system that is built by a professional developer. And then uh number three is look for chains of issues. So for example here we've found server side request forgery and then we can chain that into broken access control. So we can get to endpoints that we shouldn't have access to. And I think just to quickly prove this, if we come to slashadmin/ users, hopefully we can't just let's change the request method here. Get/admin/ users. Yeah, I see we get access denied. So we're using serverside request 4G to bypass this access denied uh control. There are lots of other things that you can check for with APIs and it's definitely if you're starting out worth checking out the OASP API top 10. I think it's from 2023. So even though it's a couple of years um ago, all of the issues on there still really apply. And common things that we're looking for are things like broken access control, broken authorization, lack of rate limiting. There are these really common issues that are really widespread currently across almost every API collection that uh we take a look at. So I hope you find this useful and I'll catch you in the next lab. So that's it for today's video. There's a lot to be learned about APIs, how they're built, typical patterns they follow, and so if you're interested in web app pentesting, abscounty, then I really do encourage you to dig deeper. and I'll catch you next