Five things you need to know about API security

An API, or Application Programming Interface, is how software talks to other software. Every day, the variety of APIs and the volume of API calls are growing. Every web and mobile application out there is powered by APIs. By nature of the APIs, many of them have a direct line to the heart of the user data and the application logic.

For example, getting control of the billing API would allow a hacker to redirect payments to his/her own accounts or mark purchases as completed, while the actual payment has not been received. Substituting a malicious or phishing API for a legitimate one can result in whole sites being taken over. We have seen catastrophic results of such actions in the recent security issues around cryptocurrency exchanges where hundreds of millions of dollars were lost.

Based on the analysis of companies that specialize in tracking APIs, such as Programmable Web, Apigee and BuiltWith, there are billions of API requests executed daily… In fact, BuiltWith’s analysis of Alexa 10K websites shows that almost 89 percent of the APIs there are internal. The other 11 percent are public APIs from SaaS providers.

Just to get an idea of the volume of traffic we are talking about, let’s look at the data for this smaller slice: public API services. Unfortunately, the data are a bit stale — they are from 2012 — which only means that the current level of traffic is much, much higher. Twitter alone had 13 billion API calls per day in 2012.

Let’s estimate the API volume from a different tack. According to ComScore, the mobile phone penetration in the US is 81 percent for folks over 13. That is 260 million US citizens walking around with 210.6 million smartphones, spending an average of three hours per day with their phones. With each application session lasting an average of five minutes and making an average of 10 API calls, that is 75.8 billion API calls per day, just to mobile backends.

Given the gravity of the threat and the sheer volume of what’s exposed, how do we develop systems that are both safe and robust? Here are five things you need to know about the API security in order to protect your applications.

One: The Types of APIs

So, what kind of APIs are out there? Broadly speaking, we can look at four categories. First is the most common category for enterprise APIs: north-south APIs. Most applications expose this type of API for exporting data, communicating to external services, management, monitoring, reporting, and other computer-to-computer communication needs.

The second category is the internal “east-west” API and it is relatively recent. As applications become more modular, individual functions are implemented by separate microservices that may be in Docker containers or otherwise isolated. All these microservices need to talk to each other and to the orchestrator, such as an application gateway or an orchestration platform, like Kubernetes.

Next, there is a large category of APIs implemented for making mobile apps work, which we alluded to earlier. The last (and growing) category is APIs for the external services being incorporated into the app. In the enterprise world, examples here might include the SalesForce API, Twilio (for communications), or Stripe (for payments).

Two: APIs Need Defense-in-Depth

With applications, we know that the external world accesses them at the perimeter. There are established practices for implementing the security there, such as demilitarized zones (DMZ). APIs are different, though. APIs are pervasive. There are internal APIs for transferring information and commands between application modules and microservices, there are APIs between mobile devices and their cloud backends, there are APIs that represent services in their own right (such as delivering traffic and weather information). This means the patterns are harder to recognize, while the risk and the need for detection and protection are higher.

With the third-party APIs used by your application, you may not even be aware of all the risks because you may not know all the parameters and supported endpoints (documentation is never perfect!) or because something has changed during the last version update.

To reduce this risk, intra-application APIs that you are using, such as east-west microservices APIs or SaaS APIs, should also be monitored for security issues at their respective ingress points. The right API security solution should be able to understand east-west microservices’ protocols’ syntaxes and, thus, to detect injections such as the Open Web Application Security Project (OWASP) Top-10 A1 class injection risks. Because microservices change often and are frequently implemented by different teams out-of-sync without corresponding changes to the configuration files, the protection system should be able to understand the syntax on the fly.

Three: APIs Need Authentication

During the design time, the most important issue is the correct implementation of API authentication and credential management. Lack of robust authentication practices can have scary consequences.

A recent article from Programmable Web looks at API security incidents at T-Mobile and Accenture. According to security researcher Karan Saini, who discovered the flaw, “T-Mobile has 76 million customers, and an attacker could have run a script to scrape the data (email, name, billing account number…) from all 76 million of these customers.”

Since common authentication methods, like password-based and biometrics authentication, cannot be used in machine-to-machine environments, the technologies one needs to look at are cryptographic authentication, challenge-response, OTP, and, more recently, blockchain.

The task gets even harder when the API is between the back-end and mobile devices. Native mobile apps present non-browser environments. No cookies, custom protocols and encodings like protobuf, different sockets management like keep-alive are supported. Furthermore, clients’ devices are completely different, ranging from cheap Android phones to the latest generation iPhones. Proof of work tasks and other CPU-memory based tests could work neither for authentication nor as strong crypto.

So API authentication is tricky!

Four: APIs Look Like Bots

API means automation. And automation means bots. Many attackers are using automation techniques to find vulnerabilities, crawl your data (like users, friends, price lists, and coupons), and do brute-force or credential stuffing attacks. There are good and bad bots operating at the same time.

Fifteen years ago, for end-user web apps, it was possible to stop bots by just implementing Captcha, JavaScript-based tasks, and some other browser fingerprinting techniques. These do not work for APIs because the API client is not a browser anymore. Tracking cookies and fingerprints are not relevant when your client/customer is a curl-based script or an external reporting server. SaaS companies make a lot of money by selling API access exactly for bots and automated processes.

The challenge for API protection is how to distinguish “bad bots” from “good bots” that are just high-volume API calls. Because these calls are high volume, the detection engine should use only passive means of detection, without injecting something to the protocol, to avoid impacting the performance.

Five: APIs Pack Heat

Unlike user-initiated interactions where one data field is presented at a time, APIs are often more complex and need to transmit more structured data in a single call. This necessitates building custom data encoding protocols because of the custom application business logic. Sometimes, to avoid escaping problems, it is necessary to encode data multiple times or apply additional logic like hashes or encryption. For example, a common case is base64-encoded data inside JSON in REST API call.

Another common example of unusual payloads in custom protocols are API calls that, at a glance, look like exploits, but are in fact legitimate and should not be blocked.

For instance, let’s look at a very popular Elasticsearch API. Suppose we have this API installed on the server and want to protect it. Some ES API methods process a “script” request field, and this field technically is where payloads should be. All the signatures for JavaScript (XSS) and other regular expression syntaxes will be triggered by this field just because it’s really actually a JavaScript that looks like this:

How are we to know that this script is completely legal here and to block all the illegal scripts at the same time? This is a big challenge for modern API protection and it is the reason why patterns and signatures are not an effective recognition mechanism anymore.

Conclusion

As an application architect, you cannot overlook design time or operational protection of APIs. APIs represent the core set of functionality for modular applications today, and their significance, impact, and sheer volume will only continue to grow in the future.

Source: thenewstack