Api Pentesting

API Pentesting

API (Application Programming Interfaces) enable software systems and applications to communicate and share data. API testing is important as vulnerabilities in APIs may undermine core aspects of a website’s confidentiality, integrity, and availability.

All dynamic websites are composed of APIs, so classic web vulnerabilities like SQL injection could be classed as API testing. In this topic we learn how to test APIs that aren’t fully used by the website front-end, with a focus on RESTful and JSON APIs. We also learn how to test for server-side parameter pollution vulnerabilities that may impact internal APIs.

API recon

To start API testing, you first need to find out as much information about the API as possible, to discover its Attack surface.

To begin, you should identify API endpoints. These are locations where an API receives requests about a specific resource on its server. For example, consider the following GET request:

GET /api/books HTTP/1.1

Host: example.com

The API endpoint for this request is /api/books. This results in an interaction with the API to retrieve a list of books from a library. Another API endpoint might be, for example, /api/books/mystery , which would retrieve a list of mystery books.

Once you have identified the endpoints, you need to determine how to interact with them. This enables you to construct valid HTTP requests to test the API. For example, you should find out information about the following:

The input data the API processes, including both compulsory and optional parameters.
The types of requests the API accepts, including supported HTTP methods and media formats.
Rate limits and authentication mechanisms.

API documentation

APIs are usually documented so that developers know how to use and integrate with them.

Documentation can be in both human-readable and machine-readable form. Human-readable documentation is designed for developers to understand how to use the API. It may include detailed explanations, examples, and usage scenarios. Machine-readable documentation is designed to be processed by software for automating tasks like API integration and validation. It’s written in structured formats like JSON or XML.

API documentation is often publicly available, Particularly if the API is intended foe use by external developers. If this is the case, always start your recon by reviewing the documentation.

Discovering API documentation

Even if API documentation isn’t openly available, you may still be able to access it by browsing applications that use the API.

To do this, you can use Burp Scanner to crawl the API. You can also browse applications manually using Burp’s browser. Look for endpoints that may refer to API documentation, for example:

/api

/swagger/index.html

/openapi.json

If you identify an endpoint for a resource, make sure to investigate the base path. For example. if you identify the resource endpoint /api/swagger/v1/users/123 , then you should investigate the following paths:

/api/swagger/v1

/api/swagger

/api

Identifying API endpoints

You can also gather a lot of information by browsing applications that use the API. This is often worth doing even if you have access to API documentation, as sometimes documentation may be inaccurate or out of date.

You can use Burp Scanner to crawl the application, then manually investigate interesting attack surface using Burp’s browser.

While browsing the application, look for patterns that suggest API endpoints in the URL structure, such as /api/ . Also look out for JavaScript files. These can contain references to API endpoints that you haven’t triggered directly via the web browser. Burp Scanner automatically extracts some endpoints during crawls, but for a more heavy weight extraction, use the JS Link Finder BApp. You can also manually review JavaScript files in Burp.

Interacting with API endponits

Once you’ve identified API endpoints, interact with them using Burp Repeater and Burp Intruder. This enables you to observe the API’s behavior and discover additional attack surface. For example, you could investigate how the API responds to changing the HTTP method and media type.

As you interact with the API endpoints, review error messages and other responses closely. Sometimes these include information that you can use to construct a valid HTTP request.

Identifying supported HTTP methods

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

For example:

GET – Retrieves data from a resource.

PATCH – Applies partial change to a resource.

OPTIONS – Retrieves information on the types of request methods that can be used on a resource.

An API endpoint may support different HTTP methods. It’s therefore important to test all potential methods when you’re investigating API endpoints. This may enable you to identify additional endpoint functionality, opening up more attack surface.

For example, 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.

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

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

For a basic understanding for API Pentesting , I turned to PortSwigger Labs. Their hand-on exercises provided practical insights into the fundamentals of API testing, helping me grasp the essentials and learn about potential risks.

Login to your Academy account and check out the lab at https://portswigger.net/web-security/api-testing/lab-exploiting-api-endpoint-using-documentation . You find it in the “All Labs” view or on the API Testing page.