A very common impression I get from some folks in the industry is that security testing API is nearly the same as testing a traditional “browser-driven” web app. Well, That’s not nearly that simple.
Till recently, traditional (browser-driven) apps have been the norm. Many of them are relatively simple stacks that “scale-out”. They usually consist of a presentation layer, a business logic/app layer, some middleware and a data source(s). These apps were built with the browser as a client in mind. However, over the last few years, Web Services has become the norm, where the application is a set of services (more popularly, RESTful Web Services) that talks to multiple front-ends, including a browser front-end, mobile apps, other apps, etc. This concept has been further streamlined to micro services and server-less architecture that are all the rage today.
A lot of the web application security practices, especially around testing, typically revolve around the older-school of applications. Attacks like Cross Site Scripting (XSS), CSRF, Session Fixation and so on are typically meant to be “browser” or “DOM” driven attacks. With the changing landscape of applications, the applicability of some of these typical testing techniques and processes should also undergo some change.
Of the many apps that we(45) tested in 2016, nearly 70% of them were web-services driven architectures, that typically behaved as APIs. While these are still “web apps”, we found that the type of attacks that were successful against these apps, were very different from the ones that used to work, say even 2 years ago. For instance, we found that Access Control attacks (attacks revolving around purely authentication and authorization) based vectors contributed nearly 50% of the findings we had, compared to earlier. Client Side Attacks like XSS have lowered numbers with these apps, and they are only “functional” when the app interfaces with a browser client or mobile web view of some sort.
On the flip side, there’s a certain (wrongful) perception with companies creating these web services. Since web services is largely considered “invisible”, many organizations do not see security testing to be a major concern.This could be because they see it as a “back end service” or because they felt that a strong front-end would neutralize most attacks that would make their way to the services themselves. Chances are that your organization has a bunch of APIs or services that it hasn’t even looked at from a security testing standpoint, and that’s dangerous.
Let’s delve into 3 ways you can win with API Security Testing:
Access Control Attacks rule the roost
One of the key differences between “browser-driven” web apps and modern web services is that there is no “user interface” or navigational flow angle to the application itself. In addition, with traditional web apps, a lot of platforms delivered authentication and authorization frameworks, batteries included. However, with web services, a lot of that needs to be built in explicitly, by your architects and developers. Therein lies the challenge. We find that authentication and authorization flaws with web services are rampant as a result. Attacks from the simple - Verb Tampering to the more complex - Forging Tokens & Insecure Direct Object references (id and Mass Assignment variants) are fair game in the Web Services world.
The worst part of this is that most or nearly all of these attacks cannot be easily identified through web security scanners. There is a great deal of manual intelligence, customized fuzzing and targeted attacks that need to be directed at such apps, to uncover Access Control flaws. You need to ensure that security testing for your API and web services has a generous dose of Access Control Testing.
Complex Stacks
The rise of web services is not an isolated event. Web Services are the result of moving to distributed architectures. And with distributed architectures, come a multitude of specialized components. Search DBs, Streaming Services, Queuing Engines, etc. to name a few. This increases the attack surface exponentially. A simple analysis of the ransomware attacks against misconfigured MongoDBs, ElasticSearch DBs and CouchDB instances should give you some idea that we have serious issues with securing the stack.
In this case, just performing an application penetration test would not suffice. I would recommend a detailed security review of various elements in the stack and the environment that it is hosted on. It is a great way of getting an inside-out and vice-versa view of the entire threat landscape.
Threat Model BEFORE the Pentest
Lack of this practice always vexes me. How do you know if the tester(s) are even addressing specific risks to your app? Most CSOs I speak to perform Threat Modeling as a static internal exercise and do not have a tactical, security tester’s view of a pentest. The best practice is to perform an Attack-driven Threat Model that captures risks, specific scenarios and attack test cases that are defined before we commence the pentest. With Web Services, this practice is all the more essential, simply because of the increased attack surface, a larger scope of threat scenarios based on the increased stack. A pre-pentest threat model also helps with correlating the model with the actual vulnerabilities identified at the end of the test.
If your pentest does not include an Attack-driven, tactical threat model before it commences, you’re really missing out!
Conclusion
Web Services and its more evolving avatars (micro-services and servers architectures) are the new normal. By subjecting them to no/limited/traditional application security testing, you’re probably missing out on a large section of critical vulnerabilities. These are some of the ways you can address challenges with testing API and Web Services and win with your Application Security Program.
