Start course

This course focuses on API Security and explains the kinds of vulnerabilities that we can find inside APIs, how to exploit them, and how to secure them as well. These skills will allow you to obtain bug bounties from vulnerabilities and also protect your own APIs as well.


Hi, within this lecture, we're going to go ahead and take a look at the API7 challenge. So, I'm going to go back to the documentation and just go for the API7 challenge. Over here, we see the title as Security Misconfiguration. It says that it's an API. So, we are expecting cross-origin requests. Great. So, it's about cross-rigin Requests. We're going to see what a cross-origin request is. But for right now, I'm just going to go ahead and take a look at the POST and GET requests. So first of all, we create a user, and then we actually log in with the user as far as I can see. After we log in, we can get a key like an authorization key I believe, with this request. And finally, we can log out from that user if we just call this endpoint. Great. Now, this is very generic. So, we sign up, we log in, we get a key, we log out. But what is cross-origin request and what does it have to do with any of this? So, cross-origin means we're getting the request from another origin. For example, not from this website, not from the API's website, from my website or from my tracker's website. So, APIs actually have to take this into consideration. Because why? Because let's assume that I'm a hacker. And I create a website and I create a button in that website to send a request to Facebook, for example. Let's assume that you are logged into the Facebook in your browser, and I placed the button in my website to send the request to the Facebook and you clicked on it. Now, Facebook receives this request through my website via my website via my server, so that I can see the request and I can see the responses and I can get something out of it. I can see the response or I can get your authorization key.

So, it's not good. It has to take this into consideration and it has to block whatever it has to block or it may just display a message saying that it's not the origin that I'm expecting but it has to follow upon on that. So, I'm going to go to Postman and just try the user name and password like atil atil123. You can try whatever you want. And as you can see once I send this request, as you can see it's created and I have my idea over here. Now, if I go to log in, now in the headers I have to have my authorization token because it's already had it's already created for me in the tests of this create user API. Now, I'm going to go and just send this without anybody and here you go. Now I'm logged in, because I have sent that authorization token. Now, so far so good.

I have created the user I have logged in. If I come over here, if I send this request, then I will get another authorization key like that. Here you go. Now user name is this password. This is an I have an authorization key. Now, I can use this authorization key to further do something inside of that website or inside of that API. Great, so far is so good. Nothing seems to be broken, and I believe we can even log out from that this one and just login back and whenever we need to. So, let's try the user log out functionality. For the last thing, I'm just going to log out. Here we go. I'm logged out. Let's try that if I logged out I shouldn't get the key. Here you go. If I send the request without logging in, I'm not getting the key. I have to log in then I can just get the key.

So, this API actually works well, but I'm going to turn the intercept on before getting the key. I'm logged in right now. I'm logged in. I will try to send this request. GET key requests and catch it in the Burp Suite. Why I'm doing that? Because I will see if I send this to repeater. If I sent this then it will give me the key because I'm logged in. API knows I'm logged in. I'm sending this cookie PHPSSID so that it knows me. It knows that I'm logged in. It will give me back my key. So, I'm going to send in. Here you go. I get the key. But, what happens if I change the origin?

I'm not going to create a website in order to do that. I'm just going to simulate it. In order to simulate it, I believe we can change some headers inside of the request. So, I'm going to search for origin header. Here you go. Cross-Origin Resource Sharing course. So, if we take a look at that, here you go. There is a tutorial over here, and that's it. As you can see, we can add the origin header whenever we need to. Great. So, this will become like this.

So, I'm going to add the origin header from here and I'm just going to change it to something random like my own website. So, right now this request is coming from my website, but the user has already been logged in. Because I'm just sending the cookie of that particular user, and here you go. Now, we got the flag. So, what happened? As you can see, the request came from another website, like a hacker's website and we still got the key. So, a hacker can easily steal our information, steal our key using that particular vulnerability. Of course, we didn't create a website from scratch. We just simulated by adding the origin header over here in the request, but that's about it. Great, so far so good. Now, I'm going to stop here, and continue within the next lecture for the next challenge.


About the Author
Learning Paths

Atil is an instructor at Bogazici University, where he graduated back in 2010. He is also co-founder of Academy Club, which provides training, and Pera Games, which operates in the mobile gaming industry.