Understanding inventory and what should or should not be part of the corporate ecosystem, control over those endpoints, incident response, policy, compliance, malware … The list of challenges is at best constant, at worst, ever-growing. It’s not a new problem but one that remains difficult to solve. It seems that infrastructure and security teams are relegated to robust reactive measures (e.g., incident response) when proactive measures are undermined by careless or thoughtless users.  

There is a certain level of irony in the fact that APIs (application programming interfaces) are often referred to as endpoints as well. Architecturally, APIs are designed to make software more extensible and offer flexibility to unique and custom use cases. Each API is defined as a contract, which accepts certain input and provides certain output. Most modern software leverages private APIs to proffer out-of-the-box functionality as well as public APIs, which users of the software may interact with to extend functionality or cater to their own specific use case. 

Much like physical (or virtual) machines on a network, APIs represent a significant viable attack surface area for would-be attackers. What’s more, command and control over APIs, how they’re built, what security mechanisms they employ, the data they expose, and how and when they are released or sunset is an increasingly challenging problem that organizations are forced to deal with.  

Security teams often aren’t advanced enough to look into what developers are deploying; documentation of APIs is often lacking; version control is often missing; and as a result, the underbelly of deployed applications is (unintentionally) exposed. Some security reports suggest that 40 to 50 percent of organizations have experienced an API breach in the last year, and research also suggests that an overwhelming volume of API traffic is malicious. Well-known companies like Peloton, LinkedIn, Experian, and John Deere have all dealt with the fallout of API security challenges. 

For the developer audience that may be interested in common weaknesses of APIs and how they’re built insecurely, consider reviewing the OWASP API Security Project. For the security architects and risk managers, there are a couple of obvious first steps to gain ground on the API challenge. 

First, you cannot protect, regulate, or inspect what you don’t know about. Discovery, much like infrastructure endpoint security, is a very critical first step. Second, once you know what’s out there, you need to gain an understanding of what type of data may be exposed by these APIs. APIs that expose sensitive data should be known, documented, and properly secured. Lastly, find out what exploitable weaknesses or vulnerabilities may be lurking in the implementation of that API (see OWASP API Security Project). 

Seems easy, right? 

Most security tooling for API security lives in runtime space. This means these tools can examine, in real-time, API calls and the data that these APIs are delivering. But in many cases, this is too late. These tools support a reactionary model that relies on stopping malicious actors just in time, if at all, and they are less capable of detecting data sensitivity concerns or vulnerabilities in the implementation of an API. 

A better way to do API security is to shift left and look at the code developers are writing. With this approach, discovery, data sensitivity issues, and exploitable vulnerabilities in API code can be identified simply by interrogating code stored in a repository. All this can be done well before any APIs are deployed in a production environment. The opportunity to trap security issues well before they are a legitimate risk, and when they’re cheaper to fix, is significant and a game-changer in the API-security space. 

API security tooling isn’t new, but it’s never been done the Checkmarx way. To learn more, check out Checkmarx API Security. 

API6:2019 – Mass Assignment:

Modern frameworks encourage developers to use functions that automatically bind input from the client into code variables and internal objects. What this means is that users should have the ability to update their user name, contact details, etc. (within their profiles for example), but they should not be able to change their user-level permissions, adjust account balances, and other administrative-like functions. An API endpoint is considered vulnerable if it automatically converts the client input into internal object properties, without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update things that they should not have access to.

Example Attack Scenario:

To illustrate this further, imagine that a ride sharing application provides the user the option to edit basic information about themselves in their user profile. For example, they can adjust their user name, age, etc. In this case, the API request would look like this: PUT /api/v1/users/me with the following legitimate information {“user_name”:”john”,”age”:24}
However, the attacker determines that the request GET /api/v1/users/me includes an additional credit_balance property (field) as shown below.
{“user_name”:”john”,”age”:24,”credit_balance”:10}.
The attacker desires to increase their credit balance on their own and replays the first request with the following payload:
{“user_name”:”john”,”age”:24,”credit_balance”:99999}
Since the endpoint is vulnerable to mass assignment, the attacker can easily adjust their own credit_balance at will, for example changing it from 10 credits to 99999 as shown above.

API7:2019 – Security Misconfiguration:

Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system they want to attack. Security misconfigurations can not only expose sensitive user data, but also system details that may lead to full server compromise.

Example Attack Scenario:

Say for instance that an attacker uses a popular search engine like Shodan to search for computers and devices directly accessible from the Internet. The attacker found a server running a popular database management system, listening on the default TCP port. The database management system was using the default configuration, which has authentication disabled by default, and the attacker gained access to millions of records with PII, personal preferences, and authentication data.

API8:2019 – Injection:

Injection vulnerabilities cause computing systems to potentially process malicious data that attackers introduce. To put it in its simplest terms, attackers inject code into a vulnerable piece of software and change the way the software is intended to be executed. As a result, injection attacks can be somewhat disastrous, since they normally lead to data theft, data loss, data corruption, denial of service, etc.

Example Attack Scenario:

Suppose an attacker starts inspecting the network traffic of their web browser and identifies the following API request designed to help a user recover their password. The attacker identifies the request responsible to start the recovery-password process as follows:
POST /api/accounts/recovery {“username“: “john@somehost.com”}
Then the attacker replays the request with a different payload:
POST /api/account/recovery {“email”: “john@somehost.com’;WAITFOR DELAY ‘0:0:5’–“}
By adding the ;WAITFOR DELAY ‘0:0:5’–” the attacker observes that the response from the API took ~5 seconds longer, which helps confirm the API is vulnerable to SQL injection. Exploiting the injection vulnerability, the attacker was able to gain unauthorized access to the system.

API9:2019 – Improper Assets Management:

Old API versions are often unpatched and can become an easy way to compromise systems without having to fight state-of-the-art security systems, which might be in place to protect the most recent API versions. Attackers may gain access to sensitive data, or even takeover the server through old, unpatched API versions connected to the same database.

Example Attack Scenario:

Say for instance that an organization redesigning their applications forgot about an old API version (api.someservice.com/v1) and left it unprotected, and with access to the user database. While targeting one of the latest released applications, an attacker found the API address (api.someservice.com/v2). Replacing v2 with v1 in the URL gave the attacker access to the old, unprotected API, exposing the personal identifiable information (PII) of millions of users.

API10:2019 – Insufficient Logging and Monitoring:

Without logging and monitoring, or with insufficient logging and monitoring, it is almost impossible to track suspicious activities targeting APIs and respond to them in a timely fashion. Without visibility over ongoing malicious activities, attackers have plenty of time to potentially compromise systems and steal data.

Example Attack Scenario

Imagine that a video-sharing platform was hit by a “large-scale” credential stuffing attack. Despite failed logins being logged, no alerts were triggered during the timespan of the attack, and it proceeded without being noticed. As a reaction to user complaints about a possible breach, API logs were analyzed and the attack was detected, way after the fact. The company had to make a public announcement asking users to reset their passwords, and report the incident to their regulatory authorities.
Pertaining to the five (5) risks above, one could easily imagine similar attack scenarios. Those provided were just examples of the nearly unlimited possibilities when attacking vulnerable API implementations. Hopefully, you can see the risks above are primarily caused by errors or oversights that could be easily remedied, especially when it comes to the way organizations utilize APIs today.