Hi Folks ! Today I am going to demonstrate how to solve the Vulnerable API lab walkthrough. You can find the link to the lab here. Although , the lab contains only basic vulnerabilities related to API , but you can learn more by doing changes in the API routes ,which is so easy in flask. So , let’s begin the API pentesting.
First part is to enumerate the api endpoints always, but keep in mind that always take reference from the web application . For ex : if the web application is related to making notes , then search for endpoints like /api/notes , /api/users/1/notes , etc. and if web application is related to some school or college work then search for endpoints like /api/grades , /api/students/1 , etc. and so on. So , keeping these points in mind I brute force the application with some of the endpoints as shown in figure.
You can see in the figure /api/users/1/notes responded with 200 status code and have also returned noted made by users but not that much information about the users. This can be reported as Excessive Data Exposures because , by default , we shouldn’t have the permission to read other notes. Now , once we confirmed that a particular endpoint exists , we should test out other Methods as well such as PUT. As you can see below, I used the PUT method by giving value to the “notesname” and “notestext”.We can test for DELETE method as well, but I would recommend to test DELETE method only on your account stuffs , otherwise it can delete some important data for other users.
Moving ahead , we will be creating an account in web application for further enumeration. As you can see there is no rate limiting protection on signup and login pages , we can brute force the /api/createusers endpoint and create many user accounts , thus can leads to DOS attack on server. This can be reported as medium severity bug. For this bug, only unique email id is required , so you can select the last character of the email id and send it to the intruder , which will do the work.
Now , on visiting the forgot password page , we can see that it ask for the email address , if email address is not present on the database , it will give the error that user not found , which can leads to a information vulnerability of user enumeration (same information vulnerability is on login and signup page). Now , on intercepting the request of forgot password we can see that , it is revealing to much information , like reset-link and token for a particular user , and thus visiting that particular url can reset the url for any account , thus leading to account takeover.
Another vulnerability is CSRF ! Yes , you heard it right , CSRF is possible even in json based application, using fetch().
The fetch() method in JavaScript is used to request to the server and load the information in the webpages. The request can be of any APIs that returns the data of the format JSON or XML.
Below is Exploit code that can be used for exploiting CSRF . As you can see , this poc will help to add a note in victim’s account on clicking the submit buttom. If you want to read about the more json based csrf , you can refer this blog.
<html>
<title>JSON CSRF POC</title>
<body>
<center>
<h1> JSON CSRF POC </h1>
<script>
fetch('http://127.0.0.1:5000/api/createnotes', {method: 'POST', credentials: 'include', headers: {'Content-Type': 'text/plain'}, body: '{"notes_name":"newcsrf","notes_text":"newcsrf"}'});
</script>
<form action="#">
<input type="button" value="Submit" />
</form>
</center>
</body>
</html>Another , vulnerability is of privilege escalation . When we were enumerating the /api/createusers endpoint , we saw that a parameter “role_ids” is being added to a user information . So , lets search if any api endpoint related to role ids are there or not.
We found that the endpoint /api/roles is giving the 200 status codes with some results as well. We can try to use the PUT method and try to escalate the account and set the role id as 1 to get the admin privileges.
So , this is all about the Vulnerable API lab . Yes ! many of the bugs are not relevant in the real world usage, but again as i said in the beginning, the main purpose is to find out the code which is responsible for the vulnerability. There can be more vulnerability in this lab , like injection or session relate bugs , also I have keep the debug mode On , so that you can observe what information could be leaked through this. If you have any suggestion or feel that code could be modified in a better way , then please point it out in the comment section or on LinkedIn. Till then Happy Hacking!!
