PortSwigger Exploiting APIs

1. Objective

2. Lab: Exploiting an API endpoint using documentation

3. Lab: Finding and exploiting an unused API endpoint

4. Lab: Exploiting a mass assignment vulnerability

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

 

1. Objective: 

This document showcases a set of hands-on API security testing exercises completed through the PortSwigger Web Security Academy. The goal is to demonstrate practical skills in identifying, analyzing, exploiting and mitigating common API vulnerabilities such as exposed API documentation, unused API endpoints, mass assignment, and server side parameter pollution in query string.

2. Lab: Exploiting an API endpoint using documentation

2.1  Description: To solve the lab, find the exposed API documentation and delete carlos. You can log in to your own account using the following credentials: wiener:peter.: 

2.2 Analysis: In this lab, the objective is to identify and exploit exposed API documentation to find and invoke a sensitive endpoint that deletes user Carlos.

2.3 What is an API exploitation? API exploitation is the act of manipulating an API to gain unauthorized access, perform unintended actions or compromise the confidentiality, integrity, or availability of an application.

2.4 What is the impact? The main impact of an API exploitation can include data breaches, account take overs, financial fraud, system disruption or full application compromised.

2.5 Steps to exploit the vulnerability: In order to target APIs, you must first be able to find them. There are several techniques to uncover the API surface using passive and active reconnaissance techniques. How an API is meant to be consumed will determine how easy it can be found. 

One way to find an API is looking through a landing page for links. Be on the lookout for obvious URL naming schemes:

https://target-name.com/api

https://target-name.com/api/v1 

https://api.target-name.com/v1 

https://target-name.com/docs

https://dev.target-name.com/rest

Look for API indicators within directory names like:/api, /api/v1, /v1, /v2, /v3, /rest, /swagger, /swagger.json, /doc, /docs, /graphql, /graphiql, /altair, /playground

Also, subdomains can also be indicators of web APIs:

api.target-name.com

uat.target-name.com

dev.target-name.com

developer.target-name.com

test.target-name.com

We look for endpoints /api and it displays a list of potential http requests: GET/DELETE/PATCH.

Open BurpSuite, open the labs and look around without login, since there is not much information, I will login with wiener:peter.

As soon as you login, you see an email update functionality.

Change email and look at the message sent to Burp, it is a Patch message, and resend it to repeater.

Go to repeater

Change the request to OPTIONS

You can see the allow http requests are DELETE, GET and PATCH, matches the documentation.

Change it to DELETE and change user to carlos that is the target.

2.6 How to mitigate it?:

·      Secure the documentation if it is not intended to be publicly accessible. 

·      Keep the documentation up to date so testers have full visibility of the API’s surface.

·      Use generic error messages

·      Use protective measure on all API’s versions.

3 Lab: Finding and exploiting an unused API endpoint

3.1 Description: To solve the lab, exploit a hidden API endpoint to buy a Lightweight l33t Leather Jacket. You can log in to your own account using the following credentials: wiener:peter.:

3.2 Analysis: In this lab, the objective is to identify and exploit a hidden or undocumented API endpoint. The ultimate goal is to purchase a Lightweight l33t Leather Jacket by leveraging an unused but functional endpoint.

3.3 What is an unused API endpoint vulnerability? An unused API endpoint vulnerability arises when a misconfigured or poorly implemented API endpoint can expose unintended functionalities to attackers.

3.4 What is the impact? The main impact of an unused API endpoint vulnerability is linked to old code, outdated security controls, can compromise unauthorized access to confidential data. 

3.5 Steps to exploit the vulnerability: As we look for information lets use the API endpoints in the URL, such as /api/ or JavaScript files. We can use Burp to scan 

Using the credentials, login and go to home to the leather jacket, there is an http GET request with /api/products/1/price → send it to repeater.

Check with OPTIONS what other http requests are allowed

The methods allowed are GET and PATCH, so let’s try PATCH

Now it says unauthorized, so let’s get the cookie session and replace it.

Now the error is pointing out that the only supported Content-Type is application/json. So let’s add it to the request.

Let’s add Content-Type: application/json; { “price”:0} and check the response.

Now the price is $0, let’s check on the website.

We can place order without credit.

3.6 How to mitigate it? 

·      Remove or disable unused endpoints. 

·      Implement proper authentication and authorization like JSON Web Token JWT, Role Based access control RBAC.

4. Lab: Exploiting a mass assignment vulnerability

4.1 Description: To solve the lab, find and exploit a mass assignment vulnerability to buy a Lightweight l33t Leather Jacket. You can log in to your own account using the following credentials: wiener:peter.

4.2 Analysis: In this lab, the objective is to identify and exploit a mass assignment via query vulnerability. In this case, the backend accepts additional parameters that the developer did not intent to allow, such as reset_token. By manipulating the request, an attacker can inject a parameter like “percentage”:0 to an unauthorized item, send the modified request and complete purchase.

4.3 What is a mass assignment vulnerability? OWASP attributes the API mass assignment vulnerability as an input validation flaw that allows hackers to perform advanced attacks by manipulating payload data. Mass assignment can inadvertently create hidden parameters, when software frameworks automatically bind request parameters to fields on an internal object.

4.4 What is the impact? The main impact of a Mass Assignment vulnerability is linked to modifying or creating variables on the server side code. Depending on the variables or objects affected, can result in compromised privilege escalation.

4.5 Steps to exploit the vulnerability:

Login with the credentials and look the Burp messages. I could not see anything useful until I added the item to the cart and click cart, then a GET /api/checkout request was sent with JSON format. I sent it to repeater.

Next, I modify the request to be Content-Type application/json; to modify the discount from 0 to 100 percent, then I changed the request to be a POST request, and the discount was applied.

4.6 How to mitigate it? 

·      Explicitly define which parameters can be mass-assigned using allow lists. 

·      Disable automatic binding. 

·      Use Data Transfer Objects, bind incoming data to a class that includes permitted fields.

·      Input validation alone does not prevent unwanted parameters but ensures the data format is correct. Log for unexpected behavior.

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

5.1 Description: to solve the lab, log as the administrator and delete carlos.

5.2 Analysis: In this lab, the objective is to identify and exploit a server-side parameter pollution in a query string. In this case, the backend accepts additional parameters that the developer did not intent to allow, such as reset_token. By manipulating the request, an attacker can get an admin password reset token, login and delete Carlos.

5.3 What is exploiting a server side parameter pollution in a query vulnerability? Some systems contain internal APIs that are not directly accessible from the internet. Server side parameter pollution in query occurs when a website embeds user input in a server side request to an internal API without adequate encoding.

5.4 What is the impact? The main impact of a server side parameter pollution in a query vulnerability is linked to manipulation or injection of parameters like overriding existing parameters, modifying the application behavior or accessing unauthorized data.

5.5 Steps to exploit the vulnerability:

To test server side parameter pollution in a query string, place a query syntax with URL-encoded characters like #(%23), &(%26) or = (%3D) and a combination of them, followed by a string like %23test and observe how the application responds. 

It helps identify if the server is truncating query strings then after the symbol # is not needed. If it does not truncate then is taking the string after the # as part of the query.

To inject invalid parameters, review the response for clues again, how the additional parameter is parsed, if the response does not change then the injected was successful but ignore by the application.

To confirm whether the application is vulnerable to server side parameter pollution, you can overriding the original parameter by injecting a second parameter with the same name. if you are able to override the original parameter you may be able to conduct an exploit passing for instance name=administrator.

Let's test the app. there is a login page, but we do not have the credentials and the usual ones are not working. There is a forgot password functionality, adding a user name like wiener, it is giving an invalid username. however administrator was valid but this is the message “Please check your email: "*****@normal-user.net"” and we got the POST request

There is also GET /static/js/forgotPassword.js with interesting information like resetToken

let's try adding at the end of administrator with encoded # and see what happens.

Error message shows field not specified, it means the query may include an additional parameter called field, that it was removed by # (%23)

Let's add uncoded &field=x

Error message shows invalid field. it means that the API may recognize the injected field parameter.

Let's send to intruder and brute force all possible server side variable names.

We got a email field with a 200 status code.

Next add email to the %26field=email23%

email is a valid parameter.

Let's go back to the /static/js/forgotPassword.js file, Notice the password reset endpoint, it refers to reset_token parameter: /forgot-password?reset_token={reset_token}

Replace email for reset_token

With the reset_token information we go to website, url /forgot-password?reset_token=juaw26wimz9wzr8ro23mgwpoluul70ow

it redirects us to create a password, then login as administrator with new password and delete Carlos.

5.6 How to mitigate it?

·      Explicitly define which parameters can be mass-assigned using allow lists. 

·      Disable automatic binding. 

·      Use Data Transfer Objects, bind incoming data to a class that includes permitted fields.

·      Input validation alone does not prevent unwanted parameters but ensures the data format is correct. 

·      Log for unexpected behavior.