2. Identifying and interacting with API endpoints

Identifying API endpoints

We can gather a lot of info by browsing apps that use the API. This is often worth doing even if we have access to API documentation, as sometimes it may be inaccurate or out of date. We can use Burp Scanner to crawl the app and then manually investigate interesting attack surface using Burp’s browser.

While browsing the app, we should look for patterns that suggest API endpoints in the URL structure, such as /api/. We should also look out for JavaScript files as they can contain references to API endpoints that we haven’t triggered directly via the web browser. Burp Scanner automatically extracts some endpoints during crawls, but for a more heavyweight extraction, we can use the JS Link Finder BApp or manually review JavaScript files in Burp.

Interacting with API endpoints

Once we have identified API endpoints, we can use Burp Repeater and Intruder to interact with them. This enables us to observe the API’s behaviour and discover additional attack surface. For example, we could test how the API responds to changing the HTTP method and media type. During our interaction we should review error messages and other responses closely as they might include info that we can use to construct a valid HTTP request.

Identifying supported HTTP methods

The HTTP method specifies the action to be performed on a resource:

• GET - Retrieves data from a resource.
• PATCH - Applies partial changes to a resource.
• OPTIONS - Retrieves info on the types of request methods that can be used on a resource.

It’s important to test all potential methods as it may enable us to identify additional endpoint functionality, opening up more attack surface. For instance, the endpoint /api/tasks may support the following methods:

• GET /api/tasks - Retrieves a list of tasks.
• POST /api/tasks - Creates a new task.
• DELETE /api/tasks/1 - Deletes a task.

We can use the built-in HTTP verbs in Burp Intruder to automatically cycle through a range of methods.

When testing different HTTP methods, we should target low-priority objects. This helps make sure that we avoid unintended consequences, for example, altering critical items or creating excessive records.

Identifying supported content types

API endpoints often expect data in a specific format. They may therefore behave differently depending on the content type of the data provided in a request. Changing the content type may enable us to:

• Trigger errors that disclose useful info.
• Bypass flawed defences.
• Take advantage of differences in processing logic. For example, an API may be secure when handling JSON data but susceptible to injection attacks when dealing with XML.

To change the content type, we can modify the Content-Type header and then reformat the request body accordingly. We can use the Content type converter BApp to automatically convert data submitted within requests between XML and JSON.

Lab: Finding and exploiting an unused API endpoint

Objective: 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.

1. We can login as wiener, and take a look at Burp Target’s Site map:

   

2. We can forward the request to Repeater and change the HTTP method from GET to OPTIONS to find out what methods are available for this endpoint:

   

   

3. Only the GET and the PATCH methods are allowed, so let’s try the latter:

   

4. It seems the request expects JSON data, so we can add a Content-Type: application/json header, pass an empty JSON dictionary, and send the request again:

   

5. We get an error message saying that the price parameter is missing, so let’s add that:

   

6. If we now refresh the page in our browser, the item’s price would have changed to $0.00. We can add it to our basket and place our order:

   

   

Fuzzing to find hidden endpoints

Once we have identified some initial API endpoints, we can fuzz to uncover hidden endpoints. For example, supposed we have identified the PUT /api/user/update API endpoint for updating user info. To identify hidden endpoints, we could use Burp Intruder to fuzz for other resources with the same structure. For instance, we could fuzz the /update position of the path with a list of other common functions, such as delete and add.

When fuzzing, we can use wordlists based on common API naming conventions and industry terms. We should also make sure to include terms that are relevant to the app, based on our initial recon.

Finding hidden parameters

When we are doing API recon, we may find undocumented parameters that the API supports. We can attempt to use these to change the app’s behaviour. Burp includes numerous tools that can help us identify hidden parameters:

• Burp Intruder enables us to fuzz for hidden parameters, using a wordlist of common parameter names to replace existing ones or add new parameters.
• The Param miner BApp enables us to automatically guess up to 65,536 parameter names per request. It guesses names that are relevant to the app, based on info taken from the scope.
• The Content discovery tool enables us to discover content that isn’t linked from visible content that we can browse to, including parameters.

Resources

• API testing.