Hi, Within this lecture, we're going to start pen testing our API finally. So far, we have made our vulnerable API run on our server. We have installed Burp Suite, and also Postman as well. Right now, we're just going to deep dive into what's going on, and why we're doing these things that we do, in order to understand it in a much better context. So right now, I have this website. In here, we have a documentation. It explains the API endpoints, like API1, API2, API3 and it gives us clues. It gives us some kind of information to solve the challenges. As you can see, it says that Broken Object Level Authorization or authentication and this is the vulnerability that it has inside of the API1. And also we have the Create User, Get User, Update User endpoints over here, with the relevant explanations. So of course, this gives us a clue and it actually gives us too much. In

the real world, if you think about it, if you're going to do an API pen testing, do you really get this kind of documentation? It depends on the situation. You may get or you may not get. Of course you won't get the vulnerabilities written down for you like this, but you may get a very detailed information. Let me show you what I mean. I'm going to just search for Instagram API or Facebook API. So, I'm just going to go ahead and go into the Instagram developer documentation. I believe this is the old one. I'm just going to go to developers.facebook.com. You don't have to do that, by the way. I'm just showing you this, this is an API that developers can use in their web applications or mobile applications. I have used it before in my mobile applications. If I go to guides, I can see the different kinds of documentations, different kind of endpoints over here. If I click on any of them, like business discovery, I can see the requests and responses. So, this is a request. This is a GET request, this is the endpoint. So, this is the version three and we see the parameters, we see the fields that we need to input, and here you go.

Now, we see what it does and what is an id? What is the parameters? What are the headers, and what kind of response do we get when we send this? So, these are the parameters for example; so as you can see, it's actually very possible that you get a detailed documentation having these sample requests and sample responses. Here we have the id of the Instagram account, here we have another request, and here we get another response like this. As you can see, it's very possible. However, Instagram does not only use this APIs. Instagram has its own APIs rather than everything listed over here. They can follow some other accounts. They can like some other accounts, they do not include this kind of API endpoints in their business development APIs, Why? Because they do not need to give access to these APIs, they do not want developers to know how to send the comment, how to like another post because they do not let them.

So, there are two options over here. You can find those APIs. You can try to pen test them; of course, if you're allowed to do so. And also you can pen test the endpoints that are listed in here as well. So far, so good. So, now I really think you understand that it depends on the situation, you may get a detailed information about the API date you are about to pen test or you may not. So depending on the situation, you get out to work harder or not. But in this case, since this is a CTF, we have this; we even have this as a collection in the Postman. So, we can do everything in a much more easier way. So, over here we have the headers and most of the time, we're not even going to bother with the headers, we're just going to work with the body. So if we send a request, we get a response back. So we have tried that this works, but right now, we're just going to deep dive into it. So first of all, I'm going to try and find the preferences of the Postman because I want to make the phones a little bit bigger. I believe you cannot see it in a clear way.

Here you go, I believe that's much better. Right now, in the body of the POST Create User request, we have sent a username and a name and a course, apparently. Like this, this was the name; this was the course that we have sent, and also we have sent a password. And for response back, we got a response and it actually includes an id. So, let me see what's going on inside of the API1. It says Broken Object Level Authorization. So, this refers to the OWASP top 10, API top 10; one of the top 10. So, this means that we can actually try to get to see the details of the other users. So, we're going to see something that we shouldn't be authorized to. So we're going to try and do that and as you can see, as a hint, it says that you can register yourself as a user. That's it. Is there something else? Let's see if there's something else. I'm going to go to the resources and see. We don't have any resources in the API1. We have in API2 and 3.

All we need to do is just work with the Postman then. So, we already created the user. We already created the user using the post request over here and we got a response back. But also, we have a Get User request over here. Most probably, we're going to get the user details giving this user id and we know the user id because it has been given to us when we have sent the request with the create user. The id is five. Now if I go to Get User, as you can see in the parameters, there's nothing in the headers, there's nothing you should change. But over here, we have an API authentication and as you can see in the API authentication we have a value. So, it has a value. It has a current value over here and it didn't have an initial value. So, where did it come from? Because we don't have anything in the body. And we even have the id over here as well, like it has id of five. So, we didn't put that information. How did it happen? So as you can see, if we have the id over here. But how does Postman know about this?

So if you go to tests, as you can see, there are some kind of JavaScript codes over here. It gets the response back; it gets the response back as adjacent request, as adjacent responsory, as adjacent responsory, and takes the id out of it. So, you don't have to do anything with these tests. The reason that I'm showing you, is that you can understand why this happens. As you can see, it gets the id and it sets the id as an environment variable. Like if I delete this and if I write five, that will be okay. But it does it for me. So, if it doesn't work for you for some reason, then you can do this manually. You can come over here and change the environment variable like the user id to five. And also for this authentication. This authentication also has been defined in the tests. As you can see, it gets the username, it gets the password, and it has an algorithm over here.

It encrypts the username, column password with some kind of encryption and it becomes the authentication key. So, this is a very standard thing to use in some kind of creating tokens when you try to do tests. And also, it's given us over here in the console; it says console.log. So, we should have seen that in the logs. I'm going to show you how to look at the logs. But also, it has it calls the Postman that set the environment variable. It saves that value as an authentication token, so that we don't have to copy and paste every time. So, if it didn't have that functionality, then we would have to go over there and copy and paste it every time. The reason that I'm showing you this; the creator of the CTF actually made it possible for us not to deal with that kind of gibberish stuff. We're not going to copy and paste values because the tests over here actually made it possible for us. It saves it automatically. In a real pen test, again, maybe you need to copy and paste stuff like take the authentication token and give it in another value in another endpoint over there. But it does that automatically for us right now. If you understood that, then it is good. So, over here as we can see, it takes the username and it takes the password, encrypts them in somehow, and it actually saves it in the API1 authentication as a result over here, and you can see the current value of that authentication token. If you don't get for some reason, you can get it from the test results. As you can see, we don't see any kind of test results over here but we can see it from the logs, I believe. Let me do that one more time.

I am just going to go into the body. I am going to create another user so that you can follow exactly what's going on. I am going to call this Zeynep, you can call this anything you want, and for the course I am just going to say mobile pentesing or mobile pentesting. I am just going to change the password as well. Now I am going to send this as a request, and I am going to open the console from here. So, I am going to open the console. And here you go. So, this already has everything over here and it already has the previous authentication token in the console as well. But if I send this, it will give me another id, it will give me another authentication token. And as you can see, we have the new authentication token. Right now, since it should have saved the id and authorization token, if we scroll down a little bit, we can see that the value has been changed right now. Right now it has the new authentication token and it should have the new API1 id as well, because we have the 6, we have the authentication token over here. Right now, if I send this get request, as you can see the current value of the id is 6. So, if you didn't get that, you can copy and paste it from here to paste for the related sections, but most probably it will work out for you fine. Now, it doesn't have anything in the body, and I am just going to just send the request because we already have all kinds of variables that we need.

So, if I send this as a request, we get the responses back like this. So, I can get the response, so everything seems to be okay. So, where is the vulnerability? So, what did I say to begin with? We should see something that we shouldn't see, in order to discover this vulnerability. Right now, I have the API authentication for user 6. But if I change this API id to user 5 for example, and just send this, as you can see, I can see the details of the user 5. And if I just send the 1, as you can see, I can see the first user, most probably an administrator user. So, it's not secure. And here we have the flag, this is the first flag. Of course, we're not even going to do something with the flags. But when we see a flag, we can understand that we solved that challenge. As you can see, we managed to get the first id, first user information using the 6th user's authentication token. So, basically, we can change and see every user detail from here, and it means that this is all the office characters I believe. I hope you're an Office fan. And also, I hope you understood that if this was a real API, then we would just create a user, and with that user's token, with that user's authorization token, we could have gotten every single user password and username or user details.

So, this is not secure. So, it should have checked the user id versus the user authentication token. If they don't match, it shouldn't have replied us back. But it did, so it's not secure. And this is the vulnerability that we were trying to find out. And this is how it goes, this is how we're going to do our pen test. I hope you understood it right now, and we're going to stop here and continue within the next one to go into the second API and find the vulnerability.

Broken Object Authorization