Lab: Exploiting an API endpoint using documentation

Task

So we are find an exposed API documentation

First, lets navigate to the webpage

Logging in with the creds we were given

We are logged in, lets head back to the “Home” page

Lets perform directory fuzzing using dirsearch

command:dirsearch -u https://0a0c004c037a9ea281dd253c00720078.web-security-academy.net/ -w /usr/share/wordlists/dirb/common.txt

We have the /api directory

Navigating to the directory you should see this

We can that to complete the task which is to delete the user carlos since we’ve gotten the endpoint to use from the documentation.

I sent the request to burp repeater,

Refreshing the webpage

We have successfully completed this lab

Lab: Finding and exploiting an unused API endpoint

Task

The task is to buy a Lightweight l33t Leather Jacket by exploiting a hidden api endpoint

Navigate to the webpage

Since we have login creds, lets login

Running a directory enumeration scan didn’t show any api directory

I did a bit of crawling with burpsuite and I got this

Send the request to repeater,

Lets try to change the HTTP method from GET to say PATCH

We got an unauthorized error, what I did was go to the browser, login with the creds I was given then captured a fresh request

From the error message we can see that our content-type is meant to be application/json.

To change the content-type to application/json I used the BApp extension content type converter

Now lets add the parameter

We’ve successfully updated the price

Now we can add the leather jacket to our cart,

We have successfully completed this lab

Lab: Exploiting a mass assignment vulnerability

Task

So the task is to exploit the mass assignment vulnerability

Navigate to the webpage

Lets do a bit of directory fuzzing using dirsearch

command:dirsearch -u https://0ac30071046b997e82cb8d7300fd0059.web-security-academy.net/ -w /usr/share/wordlists/dirb/common.txt

Navigating to the /api directory

We found an endpoint /checkout

First, lets add the leather jacket to our cart, then we’ll capture a fresh request and navigate to the /checkout endpoint

{"chosen_discount":{"percentage":0},"chosen_products":[{"product_id":"1","name":"Lightweight \"l33t\" Leather Jacket","quantity":1,"item_price":133700}]}

From the json output above we have the “chosen_discount” parameter, this means we can specify the percentage discount that applies to the product. As at this point the percentage discount is 0%, this means the price of the leather jacket is still 133700.

Now we’ll change the content-type of our request to application/json

Next thing to do is to add the json output we got from our GET request

We set the percntage discount to “100” which means we can get the Leather Jacket for free

Checking the webpage

We have successfully completed this lab

Lab: Exploiting server-side parameter pollution in a query string

Task

The task is to login as the adminsitrator and delete the user “carlos”

Navigate to the webpage,

Lets do a bit of directory fuzzing using dirsearch

command:dirsearch -u https://0a51000f039fe20b81de9d3700ec00a6.web-security-academy.net/ -w /usr/share/wordlists/dirb/common.txt

We have a /forgot-password directory

Navigating to that directory,

Lets attempt to add another parameter foo with a value bankai

We got a “parameter not supported” error, this means the the internal API may have interpreted our parameter &foo=banaki as a separate parameter.

Lets try to truncate the query string by using the character # (ensure it is url encoded)

We got a “field not specified” error which indicates that there’s a field parameter. We’ll use the parameter field and the value bankai

We still get the “invalid username”, lets change the username from “BlackAnon” to “administrator” since “administrator” is a valid username

“Invalid field” error message, this means the server-side application may recognize the injected field parameter

How do we get the correct value for the field parameter??

We’ll bruteforce hell out of it💀

Send the request to burp intruder

You can get the server-side variable names here

Start the attack,

From the screenshot above we can see that the payload “email” and “username” are valid values for the field parameter because they return the 200 status code

Lets resend the request, this time we’ll be using email as our value for the field parameter