On API Security

April 19 UPDATE - The original article doesn't discuss the drawbacks and might create false sense of security. See "Drawbacks & Assumptions" section.

For the past few months, I have been studying multiple API security companies to understand if they can solve the unique challenges faced by mobile apps. API security is about protecting server endpoints from attacks. Mostly from DDoS, bots, script injections, scrapping, etc. Most of these companies employ some kind of WAF (Web Application Firewall) to filter & inspect traffic to detect suspicious patterns, dissect attack IOCs, etc. Broadly speaking, they are focused on the following three aspects

1. Network Security - making sure the right clients connect to the server (IP allow/deny list), rate limiting, encrypt traffic, etc
2. Auth - making sure the right clients hold the right credentials to access resources
3. Data & Runtime Security - Making sure the right data is sent at the right time and frequency. This is the crown jewel feature offered by many vendors. Threat protection, DDoS mitigation, etc are all part of this component.

All these components operate on the network level, assessing signals sent on layer-7. A typical setup looks like this,

1. Agent - Is responsible for handling incoming requests. It typically sits inside your container (for cloud-native deployments) or as a standalone WAF/Gateway for legacy applications. Or as a reverse proxy in some deployments. In all of these cases, it should be able to see your incoming traffic.
2. Engine - This is the decision box - To either block or allow the traffic. This should be fairly fast as it will impact performance and lead of latency issues if not done correctly. Once a decision is made, the result is pushed out asynchronously to various processing components for storage/analysis. The decision to block a request can be statically defined (Eg. matches a known SQL injection string pattern) or dynamic through intel. sources (Eg. DDoS/malicious IP address)

For mobile devices, we have a different set of challenges. We need to verify if the device is not compromised, not forged/tampered, etc. In short, we need a solution that goes beyond network analysis. Consider the following attack scenarios

1. A compromised (rooted or jailbroken) device trying to connect to your server. Why would you trust this device? An attacker might be tampering with your API request. E.g. Rooting malware
2. A modified version of your mobile app is trying to connect to your server. Typical impersonation attack. E.g. Tampered Whatsapp
3. A malware is trying to deceive your app user to make sensitive transaction. E.g. A mobile banking user unknowingly initiates a transaction to send money to the wrong recipient. E.g ATS Fraud

Here is an ideal setup - a solution that combines both network & integrity analysis. The network aspect is already done by many innovative companies. But the latter lags behind.

Imagine this,

• The device - Will be responsible for initiating the request, most importantly it will be responsible for attaching device integrity details to the request. The latter hold crucial information about the state of the device (E.g. where its rooted, if there are any malwares, etc)
• The Agent - Parses the request to extract the network and integrity parts
• The Engine - Verify the integrity component. This involves verifying the integrity of the received input is valid (not tampered with) and data present shows the device is not compromised. I will publish more details on how this can be accomplished on my technical blog.

Challenges

There could be multiple reasons why this is not widely implemented.

• App integration complexities - For this to work, app developers need to include some kind of SDK into their apps. This is not easy as it involves, onboarding devs, writing documentation, educating devs & exec etc (Not easy to do)
• Possible latency issues at the Agent/Engine side - Verifying the integrity of a request requires some kind of cryptographic computation. While there is an opportunity to optimize, there is still a chance for latency. The customer has to accept these "drawbacks" or come up with technical wizardry to mitigate them (Possible)
• Reliability - Need to reliably verify all requests that are originating from the endpoint.

Who is doing this right now?

1. Appdome - is the only vendor right now doing that is similar to this. However, from the product demos, it's not clear how these pieces fit together. I think it's because the feature was born much later and built on top of their existing MOBILEBot™ Defense solution. The whole thing feels like it's stitched together to fit an existing product line. Secondly, judging by their documentation, it's not easy to configure the product. Almost 10-page walk through. Not ideal. There is an opportunity to solve this by making it easier to set this up with zero hassle across various WAF vendors.
2. Talsec - While it's difficult to discern intentions from their website copy, I can reasonably assume they are on the right track. I have read through their medium blogs to conclude they clearly understood the value of this. Case in point. However, they are not approaching it from a WAF perspective. They are focused on code obfuscation & RASP at this point. The server-side component is not a first class citizen but something that complements what's available at the device level.
3. Approov - Is a mobile security company that focus on API security. They do device attestation and link it to your existing API endpoints. They have SDKs for various frameworks and integration for different server frameworks (go, rust, etc). However, its far from fully automated. Developer is needed to do the integration

Opportunity

I was inspired to read and research this topic after coming across signal sciences (Acquired by fastly). Next-Gen WAF vendor. I believe there is an opportunity to build a mobile sec product driven only by WAF. This approach makes it easier to sell & explain to potential customers as they already know WAF and its uses. I have always found it difficult to explain mobile security to clients/colleagues because of the lack of common vocabulary (Or maybe I am bad at it 😉). Explaining in terms of WAF, Firewall, and Bot mitigation makes things easier 

Drawbacks & Assumptions

No security measure is 100% bullet proof. Lets discuss some of the gaps

1. Integrity Token - This token is generated at the client side. It's cryptographically signed to fend off attackers from tampering with it. However a skilled attacker can forge the entire token on a rooted device. While this is not trivial, its not impossible.
2. CI/CD Integration - While theoretically possible, it need to be verified by running a small POC
3. Automation. It might be difficult to fully automate on some of these platforms (React Native, Flutter, Cordova, etc). Hence, developer is required to do some manual configuration and setup.

References

API Security Platform - API Security Solutions - Salt Security

Salt Security’s API Security Platform discovers all APIs and their exposed data, stops attackers in their tracks, and provides remediation insights.

Salt Security

Fastly Next-Gen WAF | Fastly

The Fastly Next-Gen WAF provides web app and API protection for your apps, APIs, and microservices, wherever they live, from a single unified solution.

Fastly