Docker

Before you can setup anything else you must first download Docker, an open source virtual container manager. These containers provide a foundational workspace to run applications on, which is where the API will operate. It can be downloaded from the link below.

An important concept to note here is separation. All sandbox activity should be done on Virtual Machines (VM) or containers so that the core system is not corrupted. Due to this I utilised the open source Linux distribution 'opensuse' to run the docker. I connected to this VM from the core machine via localhost and ran the docker which acted as the platform for the API. Importantly, the IP address for this machine acts as the host for vAPI and is used to connect via browser webpage connection.

vAPI

The first tool you need to set up is vAPI, which can easily be cloned from GitHub using the link below. Once cloned it is as simple as changing directory into your new 'vapi' directory then running "docker compose up -d" to activate the vAPI. Check that the API has been setup by going to "http://(IP address of your host)/vapi/" on your browser of choice. It should show a webpage of the image below.

Postman

Following the successful setup of vAPI, Postman can now be configured to the API's domain. There is a bit more to do here compared to the first steps so follow closely.

ZAProxy

The final setup we must configure is ZAProxy. This will act as our analysis tool, capturing the requests and responses that travel through the API.

Broken Object Level Authorisation - This refers to the access control mechanisms implemented in code level that validate user object access permissions. APIs contain endpoints that receive object IDs to perform actions, but these checks may contain vulnerabilities and possible weak points.

OWASP Link - https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/

This is a simple exercise to introduce us to APIs and using Postman. Begin by using the POST request to create a new user, to customise your new user change the data in the body section of the request (Note: you cannot have two users with the same username, if you do you will receive a 500 Internal Server Error message from the server).

Use the next request in the API1 folder, the GET request to retrieve the details of the user you created. Take notice of the variable {{api1_id}}. This is the endpoint for the details we are collecting and contains a response value from the POST request we conducted before.

Now, we get to use ZAP! In the bottom section of Zap you will see a list of all requests conducted throughout the session, find the GET method we just submitted and right click on it, then click the Manual Request Editor function. This allows us to modify the request and then resend it, change the id value to 1 and see the result.

The system isn't completely insecure though. Take the details from the GET request we just received and use them as the parameters in the PUT request. You will notice that it will return a 401 Error, showcasing that there is limited authorisation within the API

Now we can understand the vulnerability and how it comes about. If endpoints are exposed and object authorisation not handled correctly, this creates a vulnerability which endangers API data. Data can become exposed and possibly leaked through manipulation of endpoint data, allowing attackers access to all kinds of information within the API.

Broken User Authentication - API endpoints handle authentication, importantly how users traverse the application and the data they can see. This involves the use of many items such as passwords, keys and tokens to protect identities and their information. If handled incorrectly this causes authentication protocols to be bypassed, leading to attacks such as brute force or man-in-the-middle, where these important items become compromised, causing identities and sensitive information to be exposed exposed.

OWASP Link - https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/

This exercise showcases password cracking and issues surrounding identity. To begin enter some random details in the body section of the request then use the POST request. You will notice that you receive a 401 Unauthorised Error, this is because we do not have excepted details.

Before moving on, take a look at the files downloaded with vAPI. Look on the device you are using as your host for the vAPI, in my case openSUSE, and change directory to (or) locate the folder vapi/Resources. You will notice a folder called API2_CredentialStuffing, this folder contains a file called creds.csv, either open or cat this file to reveal a list of details for different users.

Now we turn our attention to ZAP, we will be introducing a lot of new tools in this section so make sure to read closely. Find the POST request you just made, if you are have trouble, look along the response column for a 401 error. Inspect the request section of the message and highlight all details, then select Fuzz.

The Fuzz option is a powerful brute force tool, which will "fuzz" through a selected parameter, file or instructions, trying every option. This includes trailing numbers between a set start and end number, or if a file contained a list of usernames and passwords, it would trial each of those details. We are going to utilise it along with the credentials file to trial all the details in the file and see which ones pass the authentication.

However, this is not a simple task. The creds.csv file is not formatted correctly for the API and we have to fix that. While you could edit the file adding the necessary formatting to each line manually, it is a VERY long file, and there are extremely efficient tools which can solve this.

You will need to use linux or another command prompt option for this next step. We will be using the 'sed' command. This stands for stream editor, which acts as a very efficient editing tool, able to modify every line in a file at a set point, replacing or adding charctaers or strings. We will use it to add the proper formatting needed for the API to work. Execute the command: " sed 's/^/"email":"/' creds.csv > updatedCreds.csv " The 's' at the start dictates that it will substitute, the '^' dictates it will act at the beginning of each line and the phrase we enter is what will be substituitd in.

Now we repeat this action, but now in the middle of the strings. Execute the command: " sed 's/,/","password":"/' updatedCreds.csv > updatedCrteds2.csv ". Like before this will substitute text in, this time we set the target as a comma as each email and password is separated by a comma.

Finally we have to add the last Quotes at the end. Execute the command: " sed 's/$/"/' updatedCreds2.csv > updatedCreds3.csv " The '$' symbol sets the target to be the end of the line. With all that completed you should now have a correctly formatted file, Congrats!

Back in ZAP, in the fuzz menu select payloads on the right, then select add in the payloads window. In the add payloads window it should automatically be on Type Strings. Copy and paste the details from the updatedCreds3.csv file we created earlier, then press add and ok to finalise the windows. Now we can begin Fuzzing, hit the 'Start Fuzzer" Button.

This may take a while depending on your computational power. Luckily, we only need to find one successful entry, so set the ZAP table to code so it organises responses according to the response code. Most will be 401, but once you get a working response it will appear at the top as a 200 OK response. There should be 3 in total. Take note of the authorisation token, highlight it and copy it for later.

With that completed go back to Postman and post the GET request 'Get Details'. It will return 401 unauthorised, but thats expected, we just want to capture the request in ZAP. Find this request in ZAP, right click it and select the Manual Request Editor. Then change the Authorisation Token from null to the token you copied from the successful request. Then click the 'send' button.

You should receive a 200 OK response, along with the details (email etc) of the individual who's token you used. With that completed you have successfully made it to the end of exercise 2, good job! It was a lot more complex then the first one and introduced as to a variety of different tools so you've done well to make it through.

Now we should have a thorough understanding of the vulnerability and how it comes about. Without proper user authentication, it leaves an opening for attackers to brute force defences as we saw with the Fuzzer, and if they are able to get a hold of authorisation tokens, say for example through a man-in-the-middle attack, then they can exploit APIs and retrieve sensitive information stored within as we did through using the stolen authorisation token.

Excessive Data Exposure - When returning data after a request an API should filter the data on the client side before it is presented to the user, so that only relevant data is returned. If not designed properly an API may return other, potentially sensitive data, which while not present to the user in the application can be sniffed out by attackers and retrieved.

OWASP Link - https://owasp.org/API-Security/editions/2019/en/0xa3-excessive-data-exposure/

Following the previous exercise this one is short and sweet. This exercise is special in that it is meant to be done on an Android system, if you want you can do that by utilising tools like Anbox or Waydroid, but you can still accomplish the exercise in Postman. Begin by creating a user using the POST request Create User. 

Notice how it returns only the relevant information - this is what should occur each time a response is sent from the API. Now go above the 'Params', 'Body' etc headings, you will notice that you can change the POST option by clicking it and then selecting from the dropdown menu. We want to change it to a GET request; then go across into the address section and change 'user' to 'comment'.

Now send the request once more and look at the response it returns. It contains way too much information, a lot of which is sensitive, such as the device ID. This displays the danger of this vulnerability, and it is more commonplace then thought due to the ignorance around it. Many do not worry about sending excessive data, or assume that there is no issue since it is not displayed and therefore safe, opting to ignore filtering to save time and resources. This is a dangerous pitfall, as it doesn't matter what is displayed, ultimately whatever is sent in the response is accessible on the user side.

That concludes exercise 3, told you it was short and sweet!

Lack of Resources and Rate Limiting - Every API request consumec resources from the computer or machine it runs on. With multiple requests from diffenret API clients this creates an intense competition for resources which can lead to vulnerabilities when limits are incorrectly handled or missing. This can result in denial of service attacks as the API becomes unresponsive, or enable brute force attacks if the API doesn't stop floods of requests.

OWASP Link - https://owasp.org/API-Security/editions/2019/en/0xa4-lack-of-resources-and-rate-limiting/

Similar to the second exercise this one demonstrates the danger of unlimited response time and mismanagement of requests. To begin POST the mobile login request to initialise the login sequence. This puts the API into a state where it is expecting a PIN response for confirmation. 

Moving on to the next POST request you will see you can attempt to login with a pin. For now enter any random pin, unless you guess correctly (congratulations!) you will be unsuccessful and receive the 403 Forbidden response.

Now we switch to ZAP and follow the steps we did in exercise 2. Find the OTP POST request, select it to open the request information, highlight the PIN, right click and select Fuzz. From here select payloads then add, but for this fuzzer change the type from "Strings" to "Numberzz". This will make it fuzz from a set starting number to another set ending number, in our case choose from "1000" to "9999" to include all possible 4 digit numbers.

Finalise the fuzzer by pressing add then ok and then start it up. It may take a while depending on your computing power but eventually it will return a 200 OK response which will contain a valid OTP response code. Like with the second exercise click code to organise the responses so that the 200 OK response will appear at the top then simply wait.

Now all that is left to do is take this code, return to Postman and use the valid PIN to login. Change the OTP to the successful PIN and then POST the 'Verify OTP' request. From there move onto the GET  Get Details request, it will automatically take the authorisation token from your successful login and use it, so all you need to do is submit the GET request, which will produce details of the person whose security we have bypassed.

From our experience in exercise 2 the danger here should be obvious. Allowing unlimited requests without proper measures such as rate limiting enables brute force attacks to flood the server with requests and discover legitimate passwords, PINs and other security 'keys' leading to sensitive details being leaked. This is why many servers and even devices block users after a set number of incorrect attempts, it is a requirement for security.

On the other side of the battle, which this exercise fails to showcase, is improper resources. If an API doesn't have enough foundational support and resources then there will be competition for the server, which can be exploited. Instead of flooding the server in a brute force attack, the stream of request will produce traffic, exhausting available resources such as memory, causing the server to become unresponsive - a DoS or DDoS attack. Both of these are dangerous outcomes and highlight the importance of treading carefully with server resources, ensuring there is enough to handle stress while at the same time limiting the amount of responses given in order to avoid both attacks.

Broken Function Level Authorisation - This vulnerability is similar to exersie 1, instead acting on the action level rather tahn the data level. In modern day applications there exists a complex hierarchy of users, groups and roles which all need to be correctly coded and managed to ensure that sensitive information, administrative actions and endpoints are securely guarded. When there is a flaw in these systems it creates openings for non-administrative users to abuse admin level privileges leading to systems become exposed or compromised

OWASP Link - https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/

Begin with ZAP, because before we do anything we need an upgrade. ZAP has a dedicated add-ons section, most from the official ZAP development team, others from around the community (feel free to explore and try them out in your own time). We will be downloading the 'FuzzDBFiles' add-on. In Zap along the small second menu bar, select the option represneted by 3 squares, blue red and green. In this menu you can download and update your ZAP add-ons. Move to the marketplace tab, find the 'FuzzDBFiles' add-on and install it.

Now we can begin the exercise! Make your way back to Postman and send both the Create User POST request and the Get User GET request.

Now we return to ZAP. Find the GET request and in the request information section highlight the endpoint, then select Fuzz. Now we will use the new add-on we installed. The 'FuzzDBFiles' add-on contains a collection of predetermined texts for use in fuzzing endpoints, specifically made for testing databases, hence the DB. After selecting 'File Fuzzers' we must select the files we want to use, in our case expand 'fuzzdb', then expand the 'discovery' section and tick 'common-methods'. This contains common endpoint names used for different admin functions.

Same as before, finalise the fuzzer and start it - organise by code so the 200 OK appears at the top and wait. It shouldn't take too long until a successful response is returned - the users endpoint. This returns administrative information on the users in the database, most of which is very sensitive both for the API and the user.

Being so similar to exercise 1, most of this is reiteration on the same points. Endpoints need to be protected and correctly handled so that attackers cannot manipulate them in order to retrieve sensitive information. This is expanded now through this exercise showcasing the additional vulnerability of admin actions. These manner of attacks allow attackers to exploit the system for information, and beyond what this exercise highlighted, it also enables the creation of new users and bestowing of admin privileges, allowing attackers to embed their presence in the server and cause major damage.

Mass Assignment - In modern object orientated programming there exists many properties for differnet objects. While some are updated by client input others should not be, and should only done so through restricted methods. If an API automatically converts client input into these internal propeties without considering the exposure level of that property it opens the door for attackers to exploit object properties that should be inaccessible.

OWASP Link - https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/

This is another short and easy exercise so take a breather and enjoy the break! In Postman begin by sending the 'Create User' POST request, take note of the data it returns.

Now send the 'Get User' GET request. Compare the data retrieved to that of the early request's response, you will notice it has returned additional data in the form of a credit property.

From this additional information we can tell that the server has a hidden credit property also attached to the user along with their other information. We can exploit this. Return to the POST request and make another user, but this time add a 'credit' property and value into the body of the request.

Now resend the GET request, you should see in the response our addition was successful and our user now has additional credit.

This showcases the grave weakness of mismanaged object programming. As by exploiting the hidden, admin properties of these objects attackers can manipulate sensitive fields for their advantage or to create disruption and damages. This is most malicious when it comes to money; as salary or balance details can be manipulated. It extends beyond just danger to internal properties though, as both permission related properties and process-dependant properties can be manipulated which include admin privileges and record logs, meaning this attack can be deadly while also being covered up.

Security Misconfiguration - Arguably the most prevalent vulnerability, with the largest human cause, this comes in all shapes and sizes and can quite literally be anything, from a an out of date system to unnessary installed features, to error mesages exposing information.

OWASP Link - https://owasp.org/API-Security/editions/2019/en/0xa7-security-misconfiguration/

Start this exercise by going through the first three requests: Create a User with the POST, Login with the GET request and retrieve the key with another GET request. There is nothing special yet, we are just setting up for ZAP analysis.

Now switch over to ZAP and select the Alerts tab in the bottom menu. You will notice a list of flags which ZAP has compiled through your exercises, it has been taking note of the different vulnerabilities it has detected which can be exploited. Right now we are interested in the Cross-Domain Misconfiguration flag, expand it and select the GET request, which will be the last request we sent. If you read the description it will highlight that there is a Cross Origin Resource Sharing (CORS) vulnerability we can exploit. Move your attention to the highlighted section in the response menu, the access control is set to allow all origin points, creatint this vulnerability which we will exploit.

Return to the ZAP 'History' tab and find the GET request, then right click and select 'Open/Resend with Request Editor'. In the manual request editor add the 'Origin' property and set it to any random website. Send the request and look at the response, you should find the flag for this exercise in it.

This vulnerability is by far the simplest and easiest to occur, but it can also be the most dangerous and impactful. All it takes is one misconiguration or mistake, or an outdated model and there is something to exploit. This exercise showcased one side of this vulnerability, revealing how one small setting led to the API being exploited, on larger levels this can be more than just data exposure or base level infiltration, but can also lead to server becoming completely compromised. Making it very important that configurations are always looked over and carefully implemented.

Injection - Injection is one of the most well known attacks, often seen through SQL injection. If a system doesn't properly filter and sanitise user input then queries or other forms of system code can be input by an attacker, accepted into the system and then executed. This manipulation of the server leads into further damage through malicious code execution which can expose sensitive data or escalate attacker privileges.

OWASP Link - https://owasp.org/API-Security/editions/2019/en/0xa8-injection/

This exercise features a simple SQL injection attack. To begin send the POST request 'User Login' to attempt to login to the system. You will be met with a 403 Forbidden response.

Now transfer over to ZAP and find the POST request. In the request tab highlight the 'password' surrounded by brackets, right click and select Fuzz. That's right, its our favourite tool again!

This time we are going to do things a bit differently: At the top of the menu select 'Edit' - This allows us to edit the request, which we will use to remove the username section of the request so it is just the quotes. After this change, select 'save' which is in the same position as edit was, then highlight password and select 'Add' on the far right.

As per the usual at this point, in the payloads menu press 'Add' again. We are going to use the fuzzdb Files we downloaded previously. Change the type from 'Strings' to 'File Fuzzers' then expand the branches 'fuzzdb', folowed by 'attacks', then 'sql injection' (you will have to scroll down a bit) and finally 'exploit'. Select 'my-sql-injection-login-bypass.txt', this file contains a list of pre-written sql injection codes which will be fuzzed through. However be careful, as there are a couple of mistakes present which we must fix before finalising the payload.

Press 'Add' on the Add Payload menu, but in the 'Payloads' menu select the payload we just created, then select modify. We need to make a couple adjustment to this code in order for it to work.

For the first line add a space between the 1 and the double dashes and another space after the dashes. On the second line remove the text explaining what the command does and add a space between the first comma and OR. For the third line add a space after the double dashes and on the fourth line, remove the 1 before the double dashes. For the fifth line, add a space between the first comma and OR, add a space between the 1 and the double dashes and add a space after the double dashes. With these little tweaks we are now ready to go! Select modify to save your changes, then finalise the payload as normal by pressing 'Add' and start the fuzzer.

When it has finished running you will notice some of the requests were able to bypass the API's security and receive a 200 OK response. select one of these responses and look at the response tab of the request. You will notice in the message it returned an 'authKey'. 

Copy this and return to Postman. Select the GET request 'Get Secret' and go into the headers section. You will notice in the table there is an element called Authorization-Token, paste the authToken we took from ZAP into this field and send the request. It should return a 200 OK response, and that's this exercise complete.

Being such as well known vulnerability SQL is often accounted for in modern security, but all it takes is a single oversight in input validation and the vulnerability forms. This becomes a gateway for attackers to manipulate databases and access sensitive information. This includes actions such as executing unauthorised commands or retrieving and altering data. We were able to show through acquiring the admin's 'secret'. Due to this it is extremely important to 'sanitise' user input so that queries or code cannot be run, maintaining the health and safety of the system.

Improper Assets Management - As time goes on services receive updates and changes, of particular importance is security updates which account for new vulnerabilities and weakness. However, a vulnerability arises when old API versions are left running, as without the modern patches and updates they left in extremely vulnerable states. These old APIs can still be accessed and assaulted to retrieved details and information, bypassing the modern security system and creating this vulnerability.

OWASP Link - https://owasp.org/API-Security/editions/2019/en/0xa9-improper-assets-management/

Beginning nice and simple, send the first POST request 'Login'. It will return 200 OK, but you will notice that the pin is protected, displayed as ****.

Our goal is to break the pin, so head to ZAP, its time for another fuzzer. Find and select the request, in the request tab highlight the '****' part of the password details and open the fuzzer. Make your way into payloads and when adding the payload change the type to Numberzz. Just like with exercise 4 set it from '1000' to '9999'. Add the payload and start the fuzzer.

You will notice after a couple of requests the API begins returning 500 Internal Server errors. This API is up-to-date and equipped with rate limiting defences to protect against our attack!

To get around this lets do some investigation and find out if there is an old version still active. Go back to the history tab an find the original POST request we made, this time right click it and select 'Open/Resend with Request Editor' to open the 'Manual Request Editor'. At the top of the request where the http link is, change the 'v2' to 'v1' and then click send. A new request should pop-up at the bottom, take a look at it and you will notice that it is a 200 OK response, meaning we were successful.

We were able to reach and interact with the old API version, which may not have the same protection as the newer version so lets attack it instead. Try the fuzzer again, repeating the steps from before but this time using this new 'v1' endpoint.

After the fuzzer has started you will notice that each response is a 200 OK response, there is no rate limiting, meaning this version is unprotected. Leave the fuzzer going, but unlike previous exercises where we have organised according to code; every response is a 200 OK response because they all reach and receive a response from the server, so to find the response that successfully logs in with the pin click the table heading 'Size Resp. Body'. This will organise the table according to the response with the largest response body. Since the successful login is the only response that will return information this means it will appear up the top once it has been found.

With the successful login response found we have completed this exercise, only one more to go! This exercise clearly demonstartes the dangers of leaving old services, particularly APIs running. Not only is it a waste of resources for the system, it also creates a massive opening for attackers. As we demonstrated these version can still be accessed and misused. By changing the endpoint the old version could be accessed and manipulated leading to the complete bypassing of defence and sensitive information being leaked. It is important to be diligent of these weaknesses and remove loose ends when updating services.

Insufficient Logging and Monitoring - Monitoring and Logging events is a critical security tool as it allows for a record of events which can alert systems of possible attacks.

OWASP Link - https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%2526Monitoring

Congratulations on making it to the last vAPI exercise! This one is actually free as Postman doesn't log or monitor any of the request you send, meaning there is nothing for you to check or do. That being said if you look back at ZAP you will see a full history of every request you made throughout all the exercises. This highlights the importance of such monitoring as you can see every request made to the API, allowing you to spot malicious or suspicious activity. For example our fuzzing activity produces lots of requests, so if those were logged and reported you would know a brute force attack has been attempted on your system.