API Security

SUMMARY

A vital part of contemporary software systems, APIs (Application Programming Interfaces) allow many programs to effortlessly communicate with one another and share data.

However, just like any other software component, APIs are also susceptible to security risks that might have serious repercussions, such as data breaches, unauthorized access, and compromised systems.

API security testing enables developers to assess if an API satisfies requirements for functionality, performance, dependability, and security. To prevent users from receiving a subpar or insecure product, the goal here is to detect bugs and any other unusual behavior.

In this blog, we'll talk about

• API and its types along with its basic workflow.
• API structure, session management and authentication.
• The principles of API penetration testing and how it aids in discovering and reducing security issues.
• How to effectively do penetration testing using the OWASP Security Risks.

Introduction:

Mostly applications of all kinds are powered by application programming interfaces (APIs), which are a means of communication between programs. An API is essentially a set of guidelines that enable programs to share data in a regulated manner and allow them to connect with one another.

Below are few of the API Types:

1. Rest APIs: Representational State Transfer (REST) API. REST is one of the most used API structures.

2. SOAP APIs: Simple Object Access Protocol (SOAP) API Architectures are less common nowadays and can be mostly found used on older applications or IOT apps.

3. GraphQL APIs: This is a newer API Technology which uses a single API Call to fetch multiple resources instead of fetching them one by one independently with separate API Calls.

A basic workflow to understand how normal operations for a successful API call executes, is shown below:

Once an API Call is made from an API Endpoint (i.e users/programs), an authorization check is done by validating the API Key in the request to verify if the key is valid and expected by the server.

Before giving access to the requested resource, a Cache check is done in order to prevent re-initiation of a session and continue using a previous un-expired session.

API Structure:

Similar to waiters who take orders and bring drinks and food in a restaurant, APIs accept requests from apps and return desired data or functionality. More often than not, they do their job in REST style.

Representational State Transfer (REST), as originally defined, is an architectural design for distributed hypermedia systems. A system that adheres to the REST architecture principles is said to be RESTful.

A simple request and response overview structure is shown above.

REST API Request structure is shown below:

The above request is made to create a new user using the REST API.

REST API Response structure can be seen below: 

The server replies by sending a machine-readable representation of the requested resource rather than the requested resource itself. The same resource can be represented in a variety of forms; however, XML and JSON are the most often used ones.

A server contains hyperlinks or other hypermedia that links to other pertinent resources in the answer wherever appropriate. The server instructs the client on what to do next and what requests to make in this manner.

API Authentication and Session Management:

API Authentication is the process of verifying the identity of a user or application that is accessing the API. The most common way to authenticate an API is by using tokens or API keys, which are issued to authorized users or applications.

API Session management, on the other hand, is the process of maintaining user sessions across multiple API requests.

A basic authentication with base64 token

A JWT web authentication token

API Penetration Testing

The technique of finding weaknesses in an API (Application Programming Interface) to make sure it is protected against potential attacks is known as API penetration testing. It is a process of attempting to exploit existing vulnerabilities (if any) or finding new ones. This kind of testing simulates actual attacks on the API.

Automated vulnerability scanners, such as

• Burp Suite
• Postman
• OWASP ZAP

can be used to quickly identify common security issues such as injection flaws, broken authentication and session management, and insufficient input validation.

However, automated testing alone is not sufficient, and manual testing techniques can be used to identify more complex vulnerabilities that may be missed by automated scanners.

Finding API endpoints

Many websites provide API documentation to assist third-party developers when creating third-party applications. For instance, the documentation for Twitter's API is available at https://developer.twitter.com/en/docs/twitter-api. If the API is not meant to be utilized for public purposes, this could not always be the case.

So where else would we be able to locate API endpoints?

JavaScript documents. The endpoints must be made visible to the web application as it needs to communicate with the API, which also means it will be easy for us to locate.

Fuzzing/Scanning - Dorking for common API keywords to see if anything interesting has been indexed: site: example.com inurl:api.

Finding Vulnerabilities in APIs (Manual Methods):

When creating APIs, developers might make a range of errors, and problems with them are far more often than one might imagine. We'll look at a few methods in the sections below for testing APIs to find security flaws with respect to OWASP top 10 commonly seen security flaws:

1. Examine each parameter in each API module to gain an understanding of the data's flow from source to destination. Try fiddling with the parameter by manipulating it.

2. Find out if the API has any authorization tokens, and if it does, delete them to see the application response.

3. Examine and verify each module using users with varying levels of access, such as administrators, moderators, regular users, etc.

4. Verify whether the restricted user can access the admin modules.

5. Find the parameters that might be exposed to IDOR-type vulnerabilities and then check the cookies to see whether the IDs can be manipulated.

6. Check for injection vulnerabilities by adding special characters to every request parameter and observing the server's response.

7. Check to determine if the program encodes the greater than and less than (<,>) characters as ‘>’ and ‘<’ by inserting them into all parameters. A program may be exposed to client-side attacks like XSS (cross-site scripting) if it doesn't escape any special characters.

Hunting for specific vulnerabilities:

1. Checking for information leaks and faulty access controls: Most APIs use access tokens to determine the rights of the client. If these access tokens aren’t properly issued and validated, attackers might bypass authentication and access data illegally.

a. In most cases, majority of the bugs found under this category are called as IDORs (Insecure Direct Object Reference):

b. IDOR in simple words means to be able to modify/view other users' information by simply changing one value, typically integer value.

c. An Example Illustration is shown below of an attacker accessing another user’s profile by simply brute forcing the USER-ID Value is shown below:

2. Evaluating Rate-Limiting Issues: The API server doesn’t restrict the number of requests a client or user account can send within a short time frame.

a. Sending large numbers of requests to the server to harvest database information or brute-force credentials.

b. An example illustration showing an OTP Bypass due to rate-limiting failure is shown below:

Rate-limiting attacks might accidentally launch a DoS attack on the application by drowning it with requests, so we must time-throttle our requests carefully.

3. Testing for Misconfigured CORS: Cross-origin resource sharing (CORS) is a browser mechanism to allow controlled access to resources located outside of a given domain.

a. Many times, a website will need to access some of its subdomains or third-party websites to fetch some resources that the original website needs at that moment. This is basically a violation of the SOP (Same Origin Policy) - To relax this policy a little bit, there is something called CORS – which enables the parent's website to access and fetch resources out of different subdomains or third-party sites. But this should happen only with cross-origin domains that are explicitly allowed to be accessed in the requested resource.

b. If there is a misconfigured CORS, cross-origin resource sharing can be done from anywhere to anywhere, eventually bypassing the SOP and CORS policies as well.

c. An Example illustration of how a user’s bank details can be accessed if the server has misconfigured CORS Rules is shown below.