Richer Client, Poorer Security?

(Image © Steve Fareham (cc-by-sa/2.0))

Over the years the OWASP top 10 has been a key guide for directing application developers to the things they should worry about from a security perspective. The same types of issues seem to occur again and again with alarming regularity. The prevalence of some attack vectors like injection vulnerabilities never seems to subside. In the infamous TalkTalk breach of 2015 the 15 year old hacker involved was using a vulnerability older than he was! The OWASP top 10 project distills common attack vectors down into simple explanations that is a much needed reminder and checklist for development teams.

With the enormous growth in the use of web APIs the application security attack surface is evolving fast. Simple HTML web sites are no longer the only, or even the most common, way that we interact with the web. Rich client platforms and the predominance of mobile apps have changed the way we interact to enable a more reactive and richer experience on the client device. Rich clients have numerous security concerns and attack vectors associated with them in their own right. Indeed there is a whole OWASP Project creating a taxonomy of the potential security vulnerabilities in mobile apps.

The danger of course is to view the web and mobile app as two distinct islands of concern, with different developers or company departments worrying about the API security of each. This tendency of the richness of the mobile app can lead to poorer overall security. Who worries about the bit in the middle, the vital communication between the mobile app and the server, using an API to transfer all the confidential data? Too often developers seem to think that if they enable TLS then the communication bit in the middle is dealt with. It isn't of course. TLS simply ensures that the communication channel is encrypted end to end (and even that might not be guaranteed unless the connection is pinned properly). What is too often missed is that any API that is on the Internet is public. Anything can attempt to connect to it and if the required credentials are easily reversible from the mobile app, then that suspect connection can succeed. The web server won't know that it is not the official mobile app that is calling. So, if your security rests on only your mobile app connecting then you have a problem.

Thus it is really heartening to see this issue get the exposure it deserves in the upcoming new OWASP top 10 for 2017. There is a brand new entry at number A10, underprotected APIs. As it says, "Consider anyone with the ability to send requests to your APIs. Client software is easily reversed and communications are easily intercepted, so obscurity is no defense for APIs." Exactly! If you are making an API available on the Internet then anyone can attempt to connect to it. If you are also publishing the app that makes use of that API then you are, albeit indirectly, publishing the instructions for how to connect to your API available in the public domain. There are many tools available to help analyse an app and then to extract any buried secrets such as API keys.

Most apps that rely on an API backend have some kind of user authorization mechanism on the API - OAuth or equivalent. Accesses to the API will likely require an access token and thus valid user credentials. So you might wonder if there is really a risk for your API. Well quite possibly. For example:

• Did you really check all the possible parameter combinations that can be provided to the API, as opposed to the ones used by your app? If you tested your API only in the context of using it through your app then you probably didn't test all the possible states that can be induced by an arbitrary attacker script that can talk to your API. Something crucial might have been missed. As the OWASP A10 description says, there is a distinct lack of standard vulnerability scanners for APIs. There are good tools for traditional web sites but APIs are much lower level and custom, so automated techniques haven't yet evolved to scan their state space. Perhaps effective tools for this will never emerge - this is a much more intractable challenge. The problem is an API security bug can be as devastating as any other severe vulnerability in a web site.

• If an attacker can send an arbitrary number of requests that look like they are coming from your mobile app then this could potentially bring your servers to their knees. The attacker might be able to craft the most expensive requests, far in excess of the demand you ever expected from your real user base. This is an application layer DDoS attack. Any volumetric DDoS protection you have in place is not likely to save you as it can't tell the difference between your real customers and the attacker.

• If the attacker can talk to your API then they can try out all sorts of brute force attacks that just aren't possible from the app. Do you have the protections in place to prevent brute forcing of users passwords or pin numbers? Too often, timeouts or maximum retry limits are coded into the app, not into the API.

• Your legitimate app customers could get tricked into installing a bogus app client on their mobile device. If an attacker can steal all of the access credentials out of your app then they can build a lookalike fake app. Mostly it looks alike because they just stole all your app code. The problem is that it looks good to your customer and your API as well, so the user is fooled into typing in their credentials, and your API is fooled into communicating with the fake app. In the meantime the fake app could be doing anything with your customer's data. This is the Man-in-the-App attack.

These are all the reasons that we built Approov. It is difficult to think through all the implications of something other than your app connecting to your API. Have you really thought through all the possible attack scenarios? If you have something worth stealing behind your API then attackers can be very resourceful, and can use the anonymity of connections over the Internet to their advantage. It makes sense as an insurance policy to definitively lock the API access down to only your app so that you have complete control. This issue is much more difficult to deal with once the attackers have found a way in, and you need to continue to keep your service live for existing app customers.