Every day, there are billions of API calls being executed. These include public APIs, private APIs, SaaS APIs, APIs performing mobile back-end functions and many more.
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 some key things you need to know to protect your apps.
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 whether 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 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.
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 programmableweb looks at API security incidents at T-Mobile and Accenture (as reported byUpGuard). 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, can not be used in machine-to-machine environments, the technologies one needs to look at are cryptographics 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!
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 bruteforce or credential stuffing attacks. There are good and bad bots operating at the same time.
Ten or 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, PoW, 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.
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. If you are interested in the topic, more information about monitoring and protecting APIs is available in a recently published white paper by Wallarm: Top Five Challenges in Protecting APIs
Portions of this blog were originally published by the New Stack Magazine: https://thenewstack.io/5-things-you-need-to-know-about-api-security/
