Is Your API Security Toolbox Complete?

APIs are a key component in any digital transformation journey, enabling organizations to create new business models, connect with partners and customers, and provide a seamless experience by linking systems and services together. In our contemporary API economy, all modern architecture concepts rely on APIs heavily.

Hackers are a common presence in any digital industry and in the API economy, hackers are paying close attention to API ecosystems. OAuth 2.0 and OIDC were the default security practices used to secure APIs. With the increase in data, the severity of the data exposed via APIs, and higher usage of APIs, opportunities for attacks and the subsequent damage has also risen. In particular, exposing sensitive data such as personally identifiable information (PII) costs companies millions of dollars in repairs and results in terrible PR.

Gartner predicts that “By 2022, API abuses will be the most-frequent attack vector resulting in data breaches for enterprise web applications”. Meanwhile, KuppingerCole analyst Alexei Balaganski observes that “Many organizations still lack basic competence in the field of API security…tend to downplay API-related risks, are overconfident in their existing API security tools, and are often unaware of the extent of their operations’ dependence on APIs.”

Holding off the waves of hackers attacking APIs can often leave you feeling like the little Dutch boy trying to plug the dam with his finger. This article discusses how AI-based API security is required to detect types of attacks and how API analytics enable gaining deeper insights to support fraud detection and other anomalies.

Access delegation is the primary security requirement in an API ecosystem where someone else will access an API on your behalf and you need to delegate the corresponding access rights to the application or service. Providing end-users’ credentials or the usage of an API key is not a recommended approach anymore. OAuth 2.0 has become the norm for access delegation. When using OAuth 2.0, the access token is shared with a third party with limited access privileges and expiry time.

When the OAuth 2.0 specification was first defined, it introduced five main flows (grant types) and several new flows were introduced later with new use cases. For the implementation of OAuth 2.0 it was recommended to follow the OAuth 2.0 security best practices. Over time as the technology changed and the attack surface increased, OAuth recommendations and framework improved to cater to these challenges. This means that implementing access delegation in API ecosystem goes beyond simply implementing OAuth 2.0. It needs to follow the recommendations and enforce best practices applicable to the use case.

When discussing API security, paying extra attention to access delegation or securely managing access tokens is a key topic as it could hinder the importance of end-user authentication. Even Though username and password-based authentication is the most commonly used and convenient authentication mechanism, it is also one of the least secure authentication mechanisms.

Multi-factor authentication (MFA) emerged as an answer to this problem where a layered defense is created, making it more difficult for an unauthorized person to access a target such as the physical location, computing device, web service, network or a database. The MFA concept is based on the assumption that if one factor is compromised or broken, an attacker still has at least one more barrier to breach before successfully breaking into the target and is, therefore, more secure.

Authentication factors in MFA rely on two or more independent credentials of three categories:

Knowledge factors — Factors only known to users, such as passwords

Possession factors — Factors only owned by the user, such as ATM cards

Inherent factors — Factors unique to a user, such as fingerprints

The level of security provided by MFA ensures that it provides the best way to authenticate in the modern world. Even if one of the factors is compromised by an attacker, it is highly unlikely that all the other factors are also compromised.

Even though MFA provides high security it can still hinder usability. A static set of authentication flows are not convenient for different sets of users. Adaptive authentication is the ability to switch the authentication flow based on the context. However, adaptive authentication shouldn’t be misunderstood as a completely different mechanism that replaces MFA. Adaptive authentication orchestrates different authenticators based on the context during the user authentication process. The best part is that most of the time, users won’t even realize that the authentication process has changed. Adaptive authentication intelligently takes various factors from an authentication process and provides the authentication flow to the user.

APIs can be developed in a monolithic application or as microservices (which is a more modern approach). Regardless of the way that we develop and expose APIs, securing hundreds of APIs is not a simple task for developers, especially in microservice architectures. Microservice developers’ responsibility is only to develop the business functionality but other requirements should be managed in different layers. An API gateway is a service layer that handles these complexities for services that expose APIs at their entry points. All the requests will go through the API gateway and route back the relevant APIs.

A typical API gateway provides security (authentication and authorization), rate limiting and throttling, API composition and processing, API versioning, caching, routing, and logging and monitoring capabilities.

From an API security perspective, enforcing authentication authorization is a primary use case in an API gateway. OAuth 2.0 is used as a common security mechanism in an API gateway where the gateway plays the resource server role and validates the access token and access privileges via scopes.

An API gateway allows you to define the number of API calls that can be made for a given API resource. Then it can detect overconsumption of APIs and throttle out the excess requests, thereby helping to prevent Distributed Denial of Service (DDoS) attacks. The whitelisting or blacklisting of incoming traffic will ensure only the intended parties access exposed APIs. Processing and filtering API requests help to protect API resources against other security vulnerabilities.

An API attack vector is not limited to attacks that can be prevented using static and policy-based API security frameworks only. The following are some examples that bypass traditional API security measures.

Authentication System Attacks

• Login system attacks: Bad actors use credential stuffing and other brute force attacks to test valid credentials from the dark web to determine the validity of these credentials. They then utilize the compromised credentials to access API services. Bots may execute aggressive attacks or run slower attacks designed to blend in with normal login failures.
• Account takeover with stolen credential attacks: Stolen credentials acquired via man-in-the-middle and other attacks are used to penetrate and take over accounts. These credentials include stolen tokens, cookies, or API keys which may be used by the hacker to access data authorized to the compromised client.

Data and Application Attacks

• API takeover attacks: Hackers use a valid account to reverse engineer the API and access other accounts using the vulnerabilities they found. Theft of data and private info follows, as well as the takeover of other accounts. Meanwhile, the hacker looks like a normal user at all times since they are using a valid account.
• Data extraction or theft: Hackers use APIs to steal files, photos, credit card information, and personal data from accounts available through an API. Normal outbound activity on one API may be an attack on a different API.
• Data scraping: APIs are commonly abused by bots that extract (scrape) data for subsequent use (e.g. competitive pricing) which can negatively impact your business. Data scraping attacks can be executed on the API service directly and can run over extended time frames to avoid detection.
• Data deletion or manipulation: A disgruntled employee or hacker could delete information to sabotage systems or change data to compromise information.
• Data injected into an application service: A hacker can load large data files to overrun system memory or inject excessive data to overload an API service.
• Malicious code injection: A hacker may inject malicious code, such as keyloggers, which could compromise other users accessing the service.
• Extreme application activity: A hacker can generate calls that require unusually high system resources which can overwhelm a back-end and cause an application-level denial of service.
• Probing and fuzzing attacks: A hacker may look for coding flaws that can be exploited to expose unintended content. The hacker may also try to mask the activity by probing the API over long time periods. These attacks can be used to force API errors to uncover IP and system addresses that can then be used to access resources.

API DoS/DDoS Attacks

• Targeted API DDoS attacks: Hackers tune attacks to stay below rate limits and exploit API vulnerability with finely crafted API DDoS attacks to disable services.
• Extreme client activity: A bot or hacker may generate extreme levels of inbound activity on an API service.

In each of these scenarios, systems are attacked by exploiting vulnerabilities of users, client-side applications, authorization servers, or APIs themselves. Tokens appear to be legitimate, actions are authorized, and the hackers look like valid users. Hence it is clear that traditional API security enforcement will not help in these cases.

This is where artificial intelligence (AI) can come into the picture and help to both detect and block attacks automatically. Each API has its own access patterns and users. By leveraging API traffic, you can train a machine learning system on the client and user behavior normally exhibited and how the API itself responds in regular processing. An AI system can identify good and bad API traffic and bad actors during authentication or in API access attempts.

In this architecture, the API gateway is the primary component that intercepts all API requests and applies various types of policies. This system will then publish API request metadata and the response date to the AI system to build the knowledge base. A well trained AI system can make informed decisions when analyzing request and response flows, identify malicious actors and events, and enforce the API gateway to act upon these conditions.

Furthermore, this system can be extended to integrate the AI system with the authorization server in a way that malicious actors can be identified during authentication. In this scenario, identity management information and authentication-related information is used to push into the AI system along with the API traffic-related information. Then an adaptive authentication mechanism can be enforced over MFA during the authentication time with the input taken from the AI system. In addition, access delegation policies and token validation can be executed over-informed decisions that originate from the AI system.

Conclusion

API security is a cornerstone in any API platform where basic API access control policies alone can’t safeguard the API platform from the sophisticated security threats of today. An AI-based layered security solution provides more visibility about API activities and supports early detection of malicious activities. Integrating an AI system into both the access grant layer and the API access layer will provide a comprehensive security layer to your complete API platform.