API Testing with Postman Collections

Document created by Ed Arnold Employee on Mar 27, 2020Last modified by Ed Arnold Employee on May 5, 2020
Version 3Show Document
  • View in full screen mode

This article describes how to set up vulnerability scanning of your API using Qualys WAS with a Postman Collection.  Initial support for Postman Collections in WAS was released in October 2019.

 

Postman Collections

One of the newer features of Qualys WAS API scanning is support for Postman Collections. A Postman Collection is an executable API description available in the Postman API testing suite. Collections can be created manually or via importing a Swagger/OpenAPI/RAML/WADL file. The collection files can be local or hosted. Many QA and functional testing teams are already using Postman Collections to automate their testing and security teams using Qualys WAS may be able to leverage those collections.

 

Example vulnerable API you can download and use for testing

Tiredful API – https://github.com/payatu/Tiredful-API

 

Testing

Test Requirements

Base URL – The URL path to the API, e.g. http://10.0.0.232:8000/api/

Postman Collection – This is the collection that contains all of the API requests

Environment Variables (optional) – These are variables specific to the environment

Global Variables (optional) – These are variables that apply to all collections in Postman

 

Authentication Setup

Do not use form authentication – APIs are not HTML-based

Header injection for API keys/tokens – If access tokens are provided outside of the API, you will need to use header injection. A common example would be an API secret and API key.

 

Header injection

 

Server-based authentication is still a possibility – Basic and NTLM authentication are possible and if needed should be created as a normal authentication record in WAS.

 

Working with Postman

Postman Collection

If API documentation exists, import the file into Postman to create a Postman Collection.

Postman Import

 

If no, documentation exists, you can build the collection manually. Here is an example collection built off the Tiredful API test target. It contains the requests to the API endpoints.

 

Postman collection 

 

This request is an example of a POST request. The request goes to the endpoint, http://10.0.0.232/api/v1/trains/ and has a POST body of {“PNR”: “9875-4581-234”}.

 

 

The URL could also be held in an environment variable, {{URL}}. If that is the case, you would also upload the environment variables file.

 

 

 

Working with Data

 

This is the first request of the collection. This is a typical OAuth2 authentication flow. It is a POST request that contains a username, password, grant_type, client_id, and client_secret.

 

 

 

This is the response. It contains the access_token, token_type, expires_in, refresh_token, and scope. The access_token is the value that will need to be passed for authentication. It is similar to a cookie in that aspect.

 

 

 

One of the best features of Postman is the ability to create tests. Tests are written in JavaScript and can perform many actions. The most useful for testing is the ability to use data in the response to create variables. These variables allow passing data between requests.

 

In this example, we can capture the authentication token returned from the login request, save it as the environment variable “token” and then use it in the next request:

 

 

 

This is the next request that requires authentication. We create an Authorization header with the value Bearer: {{token}}. The {{token}} will be replaced by the variable when the request is made.

 

 

Additional Scan Considerations

Path Fuzzing Rules

Path fuzzing rules can be used to further enhance testing. APIs typically have “friendly” URLs. These URLs appear to web scanners as folders due to the way they are structured. Take this URL:

 

http://10.0.0.232/api/v1/articles/2/

 

In this example, 2 will appear as a folder. It is actually the value of the parameter articles. In a standard web application, this URL could be http://10.0.0.232/api/v1?articles=2. To ensure the scan will test the fields as parameters you will need to create rules to guide the testing.

The rule would be, http://10.0.0.232/api/v1/articles/{2}/

 

Path fuzzing rules 

 

Considerations

Order Matters 

If a call is made to store a variable, that call must come before the variable’s use in the Postman collection. If authentication is contained in the collection, the call should be first.

 

All HTTP Methods are Tested

GET – Read

PUT – Update

POST – Create

PATCH - Partial update

DELETE - Delete

 

You may want to exclude DELETE from your collection if it will result in data loss during the scan.

 

Token Lifetime 

Tokens will need to last as long as the scan. There is currently no option to use a refresh token or generate a new token during the scan.

Attachments

    Outcomes