REST API Security: Pen Tests

Security tests ensure that APIs are secure from external threats and protected from potential vulnerabilities, as discussed in one of my previous posts. The primary focus of API security tests and security testers is finding the vulnerabilities of the API that they intend to test by running penetration tests, fuzz tests, validations, sensitive data exposure determination, and so on.

This quick read discusses the importance of pen tests, stages of its lifecycle, and testing methods.

Penetration (Pen) Tests

One of the imperatives in API testing strategy is penetration testing. Pen tests are a process in the cyber-attack simulation against a system or API that exposes/determines exploitable vulnerabilities such as intra-network loopholes, XSS attacks, SQL injections, code injection attacks, and so on.

Pen tests asses the threat vector from the external standpoint, such as supported functions, available resources, and APIs internal components as well.

Importance of Penetration Tests

• No compromise to data privacy
• Guaranteed and secured financial transactions and financial data over the network
• Discover security vulnerabilities, and loopholes in the APIs in underlying systems.
• Simulate, forecast, understand, and assess impacts due to attacks.
• Make APIs as fully information security compliant

PenTest Lifecycle

Having a good understanding of the causes of vulnerabilities from the earlier section is extremely important. Now, let’s get into the five different stages of pen tests, as shown below.

The preceding diagram depicts the lifecycle of pen tests, involving five phases of activities such as preparation, scanning, gaining and maintaining access, and reporting.

Preparation, Planning, and Reconnaissance

The first phase of the lifecycle involves two parts:

• Scope definitions define the goals of the tests to be carried out and the testing methods and systems to be addressed
• Gathering intelligence, such as a domain, endpoints, and understanding how the target APIs works along with its exposure to vulnerabilities

Scanning

Understanding the target application response to various intrusion attempts by static and dynamic analysis is the focus of the scanning phase.

Gaining Access

Attempts to uncover API vulnerabilities by application attacks such as XSS (cross-site scripting), SQL injections, code injections, and backdoors. Once those vulnerabilities are uncovered, then exploiting those by privilege escalations, data stealing methods, and traffic interceptions are part of the gaining access scope and also assess the damage that API vulnerability could cause.

Maintaining Access

By establishing an illicit, long-term presence in the network, intruders may cause irreversible damages to the systems as they may present in the system for a long-term facilitates highly sensitive data mining (especially on government, military, and financial networks) in a steady, well researched, and meticulously planned attack.

Assess the long-term presence abilities and chances of gaining in-depth access to the systems/APIs — this is the primary intention of the maintaining access phase.

Analysis

The final phase of the lifecycle focus is to compile and present the results of penetration tests as a report. The report generally contains a specific vulnerability that was exploited as part of pen tests, details of compromised/accessed sensitive data as part of the pen test exercise, and most importantly, the duration of the time that one was able to remain in the system undetected. These results and reports will act as a feed/input to the security configurations across the organization to prevent any future attacks.

Hope this short read has provided a good understanding of pen tests and its lifecycle. Though there are many out-of-the-box tools available on the market to run pen tests for our APIs, it's important that one understands what pen tests are and why they are one of the key elements of an API testing strategy.

Stay tuned! In the next post, we will look at the different types of penetration tests.

Common Causes of REST API Security Vulnerabilities

Learn more about common REST API security vulnerabilities and what causes them.

As part of this article on REST API security vulnerabilities, we have gone through a few types of vulnerabilities, and with this week’s post, we observe a few common concerns or causes that make our APIs vulnerable to various attacks. Also, at the end of this article, we will quickly dive into security tests that help expose vulnerabilities as part of regression tests.

API Design and Development Flaws 

Missing or non-adhering of API security principles and best practices may lead to defects that expose the business-critical data. As another aspect of design and development, we need to keep the APIs as simple as possible (less intricate) as complexity may lead to less coverage and being vulnerable. Inadequate user input validation, SQL injection loopholes, buffer overflows are a few other causes. Understanding and implementing various aspects of design strategies and RESTful API design practices in APIs helps reducing design and development flaws to a greater extent.

Poor System Configuration

Not necessarily the best design and development is enough to safeguard the system if the system configurations (where the APIs are) do not adhere to security compliance. This introduces loopholes that attackers use to steal the information.

Human Errors

Non-adherence of organization security compliance, inadequate knowledge of security measures such as documents shredding policies, secure coding practices, choosing passwords, maintaining the confidentiality of passwords, periodical resets of passwords, no access to the unknown/unsecured sites create loopholes in the API, and more lead to security breaches.

Internal and External Connectivity

APIs are the part of unsecured internal and external network connectivity is one another major causes of the vulnerability. Also, due to APIs exposure to large and unique channels like mobile networks, poor risk management, and lenient authorization practices within the network are a few to list for this category.

So, how do we find the vulnerabilities in APIs? APIs should go through security tests.

Security Tests

Security tests ensure that APIs are secure from external threats and protected from the vulnerabilities that we have discussed above. The primary focus of the API security tests and security testers is finding the vulnerabilities of the API they intend to test by running penetration tests, fuzz tests, validations, and sensitive data exposure determination. 

Security functional testing and security vulnerability testing are the two categories of security tests. The functional test is to execute manual tests and manual checks for the presence of security mechanisms within APIs implementation. The security vulnerability tests intend to execute automated test cases that may expose vulnerabilities.

So, with a rigorous run of security tests over APIs, one can expose all possible vulnerabilities in a great time, get them fixed, and protect the APIs from those potential vulnerabilities.

RESTful API Design Principle: Deciding Levels of Granularity

Granularity is an essential principle of REST API design. As we understand, business functions divided into many small actions are fine-grained, and business functions divided into large operations are coarse-grained.

However, discussions about what level of granularity that needs to be in APIs may vary, we will get distinct suggestions, and even end up in debates. Regardless, its best to decide based upon business functions and its use cases, as granularity decisions would undoubtedly vary on a case by case basis.

This article discusses a few points on how API designers would need to choose their RESTful service granularity levels.

Coarse-Grained and Fine-Grained APIs

In some cases, calls across the network may be expensive, so to minimize them, coarse-grained APIs may be the best fit, as each request from the client forces lot of work at the server side, and in fine-grained, many calls are required to do the same amount of work at the client side.

Example: Consider a service returns customer orders in a single call. In case of fine-grained, it returns only the customer IDs, and for each customer id, the client needs to make an additional request to get details, so n+1 calls need to be made by the clients. It may be expensive round trips regarding its performance and response times over the network.

In a few other cases, APIs should be designed at the lowest practical level of granularity, because combining them is possible and allowed in ways that they suit the customer needs.

Example: An electronic form submission may need to collect addresses as well as, say, tax information. In this case, there are two functions: one is a collection of applicant's whereabouts, and another is a collection of tax details. Each task needs to be addressed with a distinct API and requires a separate service because an address change is logically a different event and not related to tax time reporting, i.e., why one needs to submit the tax information (again) for an address change. 

Levels of Granularity

Level of granularity should satisfy the specific needs of business functions or use cases. While the goal is to minimize calls across the network and for better performance, we must understand the set of operations that API consumers require and how they would give a better idea of the "correctly-grained" APIs in our designs.

At times, it may be appropriate that the API design supports both coarse-grained as well as fine-grained to give the flexibility for the API developers to choose the right APIs for their use cases.

Guidelines 

The following points may serve as some basic guidelines for the readers to decide their APIs granularity levels in their API modeling.

• In general, consider that the services may be coarse-grained, and APIs are fine-grained.
• Maintain a balance between the amount of response data and the number of resources required to provide that data. It will help decide the granularity.
• The types of performed operations on the data should also be considered as part of the design when defining the granularity.
• Read requests are normally coarse-grained. Returning all information as required to render the page; it won’t hurt as much as two separate API calls in some cases.
• On the other hand, write requests must be fine-grained. Find out everyday operations clients needs, and provide a specific API for that use case.
• At times, you should use medium grained, i.e., neither fine-grained or coarse-grained. An example could be as seen in the following sample where the nested resources are within two levels deep.

While the above guideline may understandably lead to more API deployment units, this can cause annoyances down the line. There are patterns, especially the API Gateway, that bring a better orchestration with those numerous APIs. Orchestrating the APIs with optimized endpoints, request collapsing, and much more helps in addressing the granularity challenges.