Hi. Within this challenge, we're just going to take a look at the API5. So, we already half way over there. So, let's see. This is about broken function level authorization. It sounds awful like that. The first challenge that we have completed. And it's technically something like that but we're going to see the differences. It says that you can register yourself as a user, that's it or is there something more? So, it says that I heard admin administrator logins often but uses different route. So, the key thing over here is that different route or different route, however you may want to pronounce it. And as you can see it says that you're going to have to post to this, the user and if you use a different route then we're going to get something like an administrator,  or something like maybe moderator, coordinator, or something like that.

So, over here in the Get, we're just going to send an API ID or user ID. So, this sounds like, and it works like the first challenge that we have completed really. So, I am going to just go over here and test us. So, I am going to go to create user for the headers, we're not going to change anything. But for the username and password for the body we're going to have to change something. So, we have been given something like testuser, test123, or you can just write it on your own. I am just going to go for the testuser3. I am not going to change the password, name: Test User, address, mobile number. I am not going to change any of this. I am just going to send this and here you go we get an ID back. So, this should be Id 2. Great. Now in the Get user, in the next end point, I can just try to get the user ID because I already have the authentication key as usual in the tests. So, it should have been saved to the Get user end point. If it's not, you can just look at that logs.

But here you go, it's saved in my case. So, since I already have that, I can open the logs and just compare it if you want. Here you go. This is the API5 authentication key. If it's in your case not saved, now you can just automatically overwrite it by copying and pasting over here, and here you go. In the body we don't have anything. If I send this, I can get this ID details back. Great. Now in the first challenge, we already have seen something like that. So, maybe we can try to change the ID over here like this. Like if we change it to 1, we don't get the details, so they have fixed that issue. So, it says that username or password incorrect. So, the API at the back end is checking to see if the authentication token matches with the ID so far, so good. Now if I change to Id 2, something else, I don't get it either like -1, 0, 1, 2, 3. But if I do to 2 then I can get this because the authentication key actually matches with the Id 2. But if you remember the clue, if you remember the hint, it says something about route. So, I am just going to change this to admin. As you can see, we're not still getting it. I am just going to change the ID one more time. We're not getting it.

Maybe just admin. Nope, we're not getting it. So, we're going to have to try this because we know we ought to change the route. So, I am just going to send this to Burp Suite. I am going to give some proxy. It's already been added over here. So, I am going to open the Burp Suite. I am going to turn the intercept on and I am just going to send this in a regular way and in the Burp Suite I am just going to send this to repeater as usual because we're going to repeat this process a little bit. And if I send this, I can get the second ID. But if I change the route, if I change this user to something else, then we should get it. This should be the vulnerability as long as we consider the documentation reliable source. So, I am just going to delete this and say admin for example. We're not getting it as you can see, maybe users. Here you go. In the second trial, I found it. If I change this to users, if I change this route to users, then I can get the other users details as well. So, this happens by the way in real life as well because they think that nobody knows this user's route exists, only the developer knows. So, why not we just put everything over there and for development purposes we can just use this. But the idea over here is that we're still using the same authorization token and should have checked that, but it doesn't. And we were getting this, we're getting this all details about old users. And of course, if we send this to intruder, if we send this to intruder, if we just change the route with the payload with a list, then we can just do it like we have gotten this user out of luck, right? I have just tried this and it happened. But if I add this as a parameter using the sniper attack type, I can come over here and I can use a word list or I can add one by one. Let's do an example, like I can just add anything that comes to my mind, admin, administrator, user, users, passwords, something like that, or you can just try to search word list. In Kali Linux, you can find it and just use them as well, like maybe we can try password or something like that. Just use whatever you want, like old users, admin, administrator. If you start this attack, it will just try them. And as you can see, we got the users over here. This is not luck right now. We have gotten users out of luck, I accept it, but this is not luck. This is just trying other word list, other payloads, or other routes that can be embedded in the API. And here you go. We found it and we got the flag. So, this is different than the first challenge because in the first challenge we have just changed one parameter but over here we are changing the route and using the same authorization token to get the details of every users in the database. Great. Now, if you remember this, then it's going to be okay because you can just use this technique to pen test against every possible API that's out there. If you think that there is a slight chance that you can find something like that, it would divert a lot of bug bounty money. Great. Now we're going to stop here and I am not even going to just delete the proxy because we need it as far as I see in the next challenge as well.