Understanding cyber threats to APIs

This is the fourth of a series of articles that introduces and explains API security threats, challenges, and solutions for participants in software development, operations, and protection.

Security issues for APIs

The many benefits that APIs bring to the software and application development communities – namely, that they are well documented, publicly available, standard, ubiquitous, efficient, and easy to use – are now being leveraged by bad actors to execute high profile attacks against public-facing applications. For example, we know that developers can use APIs to connect resources like web registration forms to many different backend systems. The resultant flexibility for tasks like backend update also provide support for automated attacks.

The security conundrum for APIs is that whereas most practitioners would recommend design decisions that make resources more hidden and less available, successful deployment of APIs demands willingness to focus on making resources open and available. This helps explain the attention on this aspect of modern computing, and why it is so important for security teams to identify good risk mitigation strategies for API usage.

Security threats to APIs

OWASP risks to APIs

In addition to its focus on risks to general software applications, OWASP has also provided useful guidance for API developers to reduce security risk in their implementations. Given the prominence of the OWASP organization in the software community, it is worth reviewing the 2019 Top 10 API Security Risks (with wording taken from the OWASP website):

1. Broken Object Level Authorization. APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface level access control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.

2. Broken User Authentication. Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising a system’s ability to identify the client/user compromises API security overall.

3. Excessive Data Exposure. Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.

4. Lack of Resources & Rate Limiting. Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.

5. Broken Function Level Authorization. Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

6. Mass Assignment. Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to mass assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.

7. Security Misconfiguration. Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

8. Injection. Injection flaws, such as SQL, NoSQL, command injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

9. Improper Assets Management. APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

10. Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

API security requirements

As exemplified by the OWASP list, the cyber security community is beginning to identify many familiar, canonical issues that emerge in the use of APIs for public-facing applications. Below are five generalized cyber security requirements for APIs that come up in design and development context frequently for both legacy and new Internet applications:

Visibility

The adage that knowledge-is-power seems appropriate when it comes to API visibility. Application developers and users need to know which APIs are being published, how and when they are updated, who is accessing them, and how are they being accessed. Understanding the scope of one’s API usage is the first step toward securing them.

Access control

API access is often loosely-controlled, which can lead to undesired exposure. Ensuring that the correct set of users has appropriate access permissions for each API is a critical security requirement that must be coordinated with enterprise identity and access management (IAM) systems.

Bot mitigation

In some environments, as much as 90% of the respective application traffic (e.g., account login or registration, shopping cart checkout) is generated by automated bots. Understanding and managing traffic profiles, including differentiating good bots from bad ones, is necessary to prevent automated attacks without blocking legitimate traffic. Effective complementary measures include implementing whitelist, blacklist, and rate-limiting policies, as well as geo-fencing specific to use-cases and corresponding API endpoints.

Vulnerability exploit prevention

APIs simplify attack processes by eliminating the web form or the mobile app, thus allowing a bad actor to more easily exploit a targeted vulnerability. Protecting API endpoints from business logic abuse and other vulnerability exploits is thus a key API security mitigation requirement.

Data loss prevention

Preventing data loss over exposed APIs for appropriately privileged users or otherwise, either due to programming errors or security control gaps, is also a critical security requirement. Many API attacks are designed specifically to gain access to critical data made available from back-end servers and systems.

The API community continues to drive toward more standardized agreement on the optimal approach to security. To this end, industry groups such as OAUTH, for example, have proposed criteria requirements for API security that are quite useful. The most likely progression is that the software security community will continue to refine its understanding and insight into the full range of API security requirements in the coming years. Observers should thus expect to see continued evolution in this area.

API security methods

API abuse in action

By design, APIs are stateless, assuming that the initial request and response are self-contained, holding all the information needed to complete the transaction. Making program calls to an API directly, or as part of a mobile or web application improves user experience and overall performance. This makes it very easy for a bad actor to script and automate their attack as highlighted in two examples below

Account takeover and romance fraud: Zoosk is a well-known dating application. Bad actors decompiled the Zoosk app to uncover account login APIs. Using automation and attack toolkits, they then executed account takeover attacks. In some cases, compromised accounts were used to establish a personal relationship with another Zoosk user and, as the relationship blossomed, the bad actor requested money due to a sudden death or illness in the family. The unsuspecting user gave the money to the bad actor, who was never to be heard from again. Prior to implementing Cequence, romance scams at Zoosk averaged $12,000 with each occurrence. Now, they are virtually eliminated, resulting in increased user confidence and strengthened brand awareness.

Account takeover and financial fraud: Another example of APIs being targeted with an automated attack involves a large financial services customer finding that attackers had targeted its mobile application login API to execute account takeovers. If successful, the bad actors could attempt to commit financial fraud by transferring funds across the Open Funds Transfer (OFX) API. OFX, of course, is the industry standard API for funds transfer within the financial services community, and as such the APIs are publicly-available and well-documented to facilitate use.

The ubiquity and stateless nature of APIs are beneficial in many ways, but they also introduce numerous challenges that traditional security technologies cannot address. By design, APIs do not have a client-side component, so traditional defense techniques like Captchas or JavaScript and mobile SDK instrumentation cannot be used elegantly to prevent an automated attack. Often, there is no corresponding browser or mobile application for redirection and cookie assignment for instrumentation. The result is that the API and associated application are left unprotected, or are protected only partially.

Contributing author: Matthew Keil, Director of Product Marketing, Cequence.