Offensive Security Researcher & Quantum Cryptography Analyst

API Documentation: A Hacker’s Goldmine for Vulnerability Hunting

Abdul Wahab Junaid
API Documentation: A Hacker's Goldmine for Vulnerability Hunting

Introduction

The vast majority of vulnerabilities found in Application Programming Interfaces (APIs) are the result of a design flaw. If a security professional has access to the API documentation, these flaws can be fairly easy to locate.

For example, suppose an application has a password reset endpoint that takes a user_id and a new_password as its input parameters. A security tester should immediately consider checking for Insecure Direct Object Reference (IDOR) to see if they can reset other users’ passwords. These types of design flaws can be relatively easy to spot when the API documentation lists all the available endpoints and their specific parameters. While it’s possible to manually inspect network traffic to find this endpoint, having the API documentation makes the process significantly easier and faster.

Swagger API: The RESTful Goldmine

Swagger is a very popular API documentation language used for describing RESTful APIs [Representational State Transfer Application Programming Interfaces], typically expressed using JSON (JavaScript Object Notation). If an application is using a REST API, a security tester will typically start by looking for common Swagger endpoints:

As shown in the image below, Swagger documentation provides the name, path, and arguments of every possible API call. When testing API functionality, this documentation is a gold mine. Clicking on a specific request will expand it, allowing the tester to perform all of their testing directly within the documentation interface.

Seeing the image above, one might immediately think to test for an insecure redirect vulnerability due to the presence of a redirect parameter. When reviewing the documentation, the tester typically looks for design flaws, authentication issues, and issues related to the OWASP Top 10. Security professionals have personally found hidden password resets that are easily bypassable, hidden admin functionality that allows complete site control when unauthenticated, SQL Injection, and much more simply by analyzing these documents.

Reflected and Persistent XSS in Swagger

As Swagger is a popular tool, it is bound to have some known exploits. Security testers have personally found reflected Cross-Site Scripting (XSS) on several Swagger endpoints during testing. A while ago, a flaw was found on the url parameter:

This vulnerability allows an attacker to inject and execute arbitrary JavaScript code when the victim accesses the specially crafted URL. For clarity, atob("SGVyZSBpcyB0aGUgWFNT") decodes to “Here is the XSS.” This specific issue has been documented in the official GitHub repository for swagger-api/swagger-ui.

A tester can also achieve persistent XSS if they supply the Swagger documentation endpoint with a malicious file to parse:

This issue has also been previously tracked on the swagger-api/swagger-ui GitHub repository. If a tester happens to stumble across some Swagger documentation, it is an excellent idea to check for these two XSS vulnerabilities early in the testing process.

Postman: The Universal API Client

According to Google, Postman is “a popular API client that makes it easy for developers to create, share, test and document APIs. This is done by allowing users to create and save simple and complex HTTP/s requests, as well as read their responses.” Basically, Postman is an essential tool that can be used to read, write, and interact with API documentation.

The tool can be downloaded from the official website.

What is particularly nice about Postman is its ability to import API documentation from multiple sources. For example, while Swagger APIs can be loaded from their official documentation website, a tester could also use Postman for this. The process simply involves loading the Swagger JSON file into the client.

Once the API documentation is successfully imported into Postman, the next crucial step is to review each API endpoint and systematically test it for vulnerabilities.

WSDL: Describing SOAP Web Services

WSDL [Web Service Description Language] is, according to Google, “an XML vocabulary used to describe SOAP-based web services.” In other words, the WSDL file is the documentation used to describe the endpoints, data types, and operations of a SOAP [Simple Object Access Protocol] API.

WSDL files are fairly easy to spot during reconnaissance. A security professional will look for an XML file that contains a “wsdl” tag. When hunting for these files, they will typically appear in URLs like the following:

The WSDL file can then be imported into a specialized tool like SoapUI.

This tool can be used to create request templates based on the WSDL structure. These templates can then be sent to the target server. All the tester has to do is fill in their values for the parameters and hit “send” to test the endpoint.

WADL: The REST Equivalent of WSDL

According to Google, WADL [Web Application Description Language] is “a machine-readable XML description of HTTP-based web services.” You can think of WADL as the REST equivalent of WSDL. As a general rule, WADL is typically used for REST APIs, while WSDL is typically used on SOAP endpoints.

WADL files should look similar to the image above, being an XML-based format. When hunting, a tester should be on the lookout for an XML document ending with “wadl” as shown below:

Once the target’s WADL file is found, it can be imported using an API client like Postman. The next step is to review the API documentation to gain a better understanding of the application’s structure and functionalities. This deep understanding will significantly help the tester to identify vulnerabilities later down the road.

Summary and Conclusion

API documentation is one of the best resources to have when probing an API for security vulnerabilities. If a security professional is testing an API endpoint, they will typically start out by looking for the corresponding API documentation. This provides an understanding of the API and all the functionalities it contains. Once the application’s structure is understood, the tester can start to find design flaws and other bugs fairly easily.

If you come across an API endpoint, the first step is to figure out what type of API it is (e.g., REST, RPC, SOAP, or GraphQL), as the testing methodology will change slightly depending on the technology.

It is important to note that APIs share the same vulnerabilities as every other web application, so make sure to look for SQL injection, XSS, and all the other vulnerabilities on the OWASP Top 10 list.

Testers also want to keep a sharp eye out for the API documentation, as this can be extremely useful to an attacker. Attackers can use the API documentation to find design flaws, hidden endpoints, and gain a better understanding of the application’s logic. In addition, always pay attention to the authentication process, as there could be several attack avenues here depending on the underlying technology.

Exit mobile version