API Security Testing(Part 1)
All the information mentioned in this article are of my personal and aren’t the opinions of my past or present employer.
API Security Testing — It’s a little complicated area for a Pen tester on my personal experience. Though the overall testing can be simplified by understanding the API documentation thoroughly. In the real-world scenario, the pen tester team has limited time span for completing the activity. It differs company to company though.
What’s an API?
API stands for Application Programming Interface
If you want to understand how API works, please remember your order at Subway. Where you choose your own bread, your ingredients, etc for ordering food with a menu available. Similarly, API lists number of operations that developers can use with the descriptions what those operations can do.
An API is all means to make the developer’s life easy. It controls resources and It controls resources and communication between services. For example, you might have seen multiple times that your web browser wants to know your location. That’s an API call in layman terms. Figuring out your GPS location and destination is done by Application.
Now, most of the Pen Testers have doubts over the API and Web Services. Are the API and Web Services tests the same or different?
Both are means of communication, when its Web Services, the communication happens over the internet. You can say all the web service security tests are API security test, but all the API Security test are not web service security tests.
API communication happens between applications, it might be over intranet or internet. So usually you will find the test cases are the same and the tools (usually POSTMAN) we use to access are the same.
Now let’s focus the security flaws in the API calls.
There are two types of API. One is REST another is SOAP. You can say REST is new while SOAP is older. In terms of layman, SOAP is complex compared to REST. Few more things about both to satisfy your technical curiosity.
SOAP — Simple Object Access Protocol
REST — Representational State Transfer
From its abbreviation, you now know that SOAP is a protocol while REST is an architecture.
From the security point of view, we will discuss only the major differences not all of them.
SOAP API is made of an official standard while REST API is not. This makes in fact REST API is easy to use and deploy.
REST uses: HTTP, JSON , URL and XML
SOAP uses: mostly HTTP and XML
Due to those reasons, REST is more popular among developers than SOAP. One more reason is “ REST APIs are more convenient with JavaScript”. Though SOAP has compatibility with JavaScript, its support with larger implementation is limited. So, you find SOAP mostly with legacy application nowadays.
As a security analyst point of view, I am little biased towards SOAP as it offers lesser entry points to a hacker. Why this thought? Because it supports only one output type XML and REST supports XML, JSON, sometimes CSV.
Apart from it, what makes SOAP more secure than REST?
Both formats support Secure Sockets Layer for data protection during the transfer process, but SOAP also supports WS-Security for enterprise-level protection. It might have answered your query now.
When you’re dealing with crucial private information like bank account numbers, it makes more sense to use SOAP. However, SOAP’s extra security isn’t necessary if you’re sending the day’s forecast to a mobile application.
We leave it to the developer when it comes to choosing between REST and SOAP.
Now let’s come to the test cases and set-up of tools and environment. You can use both free and paid version here. Free Version tool is also efficient enough for completing a thorough test.
Tools: POSTMAN and Burp suite
OS: Windows platform
POSTMAN: https://www.getpostman.com/downloads/
Burp suite: https://portswigger.net/burp
Once you download, it’s as simple as installing normal applications. Please find the screenshots below for POSTMAN. It will look like this. You can log in with your mail or you can skip it also.
As here it’s assumed that the pen tester has basic knowledge of pen test activity, s/he will be familiar with burp suite installation and proxy setting. As it’s an API security test-oriented article, only parts related to API Pen Test would be covered.
Now you can go to the FILE tab and then SETTINGS, there you can set up your proxy to take up your all requests in Burp for ease of testing.
Now once the set up is done, we are all set for the Pen test.
Please remember one most important thing that API documentation collection and Walkthrough with the developer team must be conducted before the test. Otherwise, we won’t understand much for our testing. Without API documentation. Everything will be the shots in the dark.
One more tip for you, if you can collect sample API calls and environment from the developers, it will be a complete cakewalk.
You can simply import API calls and environment, which will save you a lot of manual work.
IMPORTING API CALLS:
SETTING UP ENVIRONMENT VARIABLES:
Let’s begin:
STEP 1: As we know that without login to the web application, we cannot view/use all the functionalities. Same way, API requires authentication token for login. In this case, json token example is given.
Analyze the access token: One of the most important vulnerability checking must be done here.
If you go to the site https://jwt.io/ , there you’ll find the below picture:
It’s a JSON token which is the base64 encoded value. It’s a combination of 3 parts HEADER, PAYLOAD and SIGNATURE.
If you look at the above picture, you will find that HEADR contains algorithm(alg) and its type(typ). Here the algorithm is HS256 and type is JWT (JSON Web Token).
HEADER is of user name and password. SIGNATURE is of hashed value of a secret value. Now here you can perform Session Management related tests, sensitive data exposure test.
STEP 2: Apart from an access token, there you’ll find a refresh token. It plays a major role for keeping the user logged in post-authentication.
What’s a REFRESH TOKEN and why they come to the picture?
Refresh tokens represent the information necessary to get a new access token. In technical terms, whenever an access token is required to access a specific resource, a client may use a refresh token to get a new access token issued by the authentication server.
Test cases with REFRESH TOKEN:
· As it’s also base64 encoded as the access token, you will find similar features as access token.
· Session Management test cases and Sensitive Data Exposure test cases are applicable as access token.
· Expiry date duration matters. As per their nature Refresh tokens are long-lived compared to access token.
STEP 3: Input Validation Test
· Check all the Injection entry points.
· Test with commend injection, html injection and sql injection.
· If applications are vulnerable to injections, closely followed by thorough automated testing of all parameters, headers, URL, cookies, JSON, SOAP, and XML data inputs.
As a basic example, say you send a request to an API, and within one of the query parameters, you have the following command: ?command=rm -rf /. If the API does not properly sanitize or validate that data within that parameter, it could potentially run that command, destroying the contents of the server.
Obviously, command injection can be one of the most detrimental vulnerabilities for any web service. Here's a couple of ways to test for these vulnerabilities:
Operating system commands in API requests
A good starting point is to determine the operating system the API runs on, generally Linux or Windows. From there, attempt to send commands within the API request that would run on that OS. Take the following case where an API request deletes a file by name:
$fn = $_GET['filename'];system("rm $file")
If a user's request sends a malicious command in the filename parameter, it would be executed:
https://example.com/delete?name=file.txt;rm%20/This example is from the OWASP wiki
As a software tester, it's good to familiarize yourself with different operating systems and commands so you can get creative in in these tests.
STEP 4: API Authentication Test
Though you would find many auth related issues could be figured out from token analysis. User session management issues must be looked closely like:
· User privilege escalation test: For example, access\refresh token of one user shouldn’t be accepted by another user.
· The “id” parameter in the users: are they sequential? This question should be asked and answered while testing.
Contd…..
Please follow me on Linkedin.
