App and API Security That Tastes Good Used properly, is a simple and effective security tactic to minimize attack surfaces. If you’re not on the list, you don‘t get in. No exceptions. Smooth as chocolate. If it’s too easy for you to find and spoof a name on the list, use to make it harder. Sticky as peanut butter. Together they taste great. whitelisting indirection App Whitelisting A whitelist is a list of the only entities allowed to access a particular resource. Each entity is identified by one or more identifiers, such as user id, ip address, port number, or API key. It is important that these identifiers specify unique entities and that these identifiers cannot be easily mimicked by other entities. If the list of allowed entities is small and slowly changing, then maintaining the list is quite practical. For example, if you provide a health care mobile app which communicates with your back-end services through an API, then your authorized app whitelist consists of released and approved versions of your mobile app. Versions can be added and removed from the list as features are added and retired. API calls will only be permitted if they include an app version’s identifier which is on the whitelist. Apps often make API calls to a variety of different services. What makes a good white list identifier? Google Maps Android API To use the , you must register your app project on the Google API Console and get a Google API key which you can add to your app. From a web page, you make a call to the map service appending YOUR_API_KEY: Google Maps API center=Brooklyn+Bridge,New+York,NY&zoom=13&size=600x300&maptype=roadmap&markers=color:blue%7Clabel:S%7C40.702147,-74.015794&markers=color:green%7Clabel:G%7C40.711614,-74.012318&markers=color:red%7Clabel:C%7C40.718217,-73.998284&key= https://maps.googleapis.com/maps/api/staticmap? YOUR_API_KEY It is very common to use a static API key to stand in as an app or developer identifier, but how safe is it? There are two basic types of attack, reverse engineering the app code to find the API key, and observing the API key in transit during an API call. On a web page, finding the API key may be as simple as looking at the page source in your browser. In an Android app, Google suggests placing the key in the manifest file, but that is easy to read by . Even though the Google maps API call uses HTTPS, if you can mount a , you can directly observe the API key being transmitted. decompiling the APK Man-in-the-Middle attack You can try to , but that only slows down a determined attacker. For the Android maps API, Google recommends restricting access to the signed app’s fingerprint, but this is ultimately just a second static key to determine, more difficult, but not impossible. hide API keys through obfuscation or encoding API Gateways David Wheeler is often quoted as saying So if hiding static API keys is hard, why not move them off the app and behind a proxy server which can indirectly make the calls for you? “All problems in computer science can be solved by another level of indirection.” With this configuration, a client app makes an API call without the API key, and the proxy server redirects the API call, appending the appropriate API key. The key is not stored in the app, nor is it ever transmitted between client and proxy. That’s a good start, but have we really gained anything? Although we’ve removed the API keys from the app, now anyone can call the proxy, unless, we create a new app whitelist for the proxy sever, which means a new static identifier, which we’ll call the shared app secret. Sounds like the same problem all over again. However, most apps make API calls to multiple 3rd party services. At least the API keys for all these services can now be secured behind the proxy. This makes the security of the single app secret all the more critical, but now all the API services can be centrally managed. API keys can be updated separately from the apps, and usage can be centrally logged and rate limited. Most commercial and open-source API gateways provide best practice implementations of these features. App Authentication Services Let’s try one more level of indirection for that remaining shared app secret. This time, we delegate identification of the authentic app to an external service. The app secret is known to both the API proxy and the authentication service but is never directly shared with the app itself. Instead, if authentication succeeds, the app secret is used to an app authentication token which is returned to the app. The app then passes the token to the API gateway with each API call. Using the app secret, the API gateway verifies the token signature before redirecting the API call, along with the appropriate API key, to the 3rd party service. cryptographically sign Though the secret is static, a token needn’t be. The lifetime of the token can be very short lived by giving it an expiration time, limiting the number of times it can be used or both. This way, if a token is somehow stolen, its value is quite limited. As each token expires, an app can request a new authentication and receive a fresh token. Further, the authentication service itself can evolve over time, improving authentication strategies and/or adding additional secondary identifiers to the token. Attesting the app identity periodically and returning time-limited tokens are big benefits of indirection over static identifying keys. A Practical Implementation At CriticalBlue, we have combined whitelisting with indirection to build the app authentication service for mobile apps. Using Approov, only authentic and authorized apps can call your back-end APIs. Approov You first drop the Approov SDK into the app to enable communication with the authentication service. Next, you register your app with the authentication service which enables strong app attestation and generates the app secret shared between the service and your back-end server or API gateway. To see it in action, you can download and try an for Android or iOS. For more detail, you can follow a showing how to remove all secrets from an app using both an API proxy server and an authentication service. app demo Hands On Mobile API Security tutorial Combining an app authentication service with user authentication services such as / greatly reduces the attack surface present with user authentication alone. OpenID-Connect OAuth2 Android may have its treats, but for app and API security, whitelists and indirection are their own taste sensation. Thanks for reading! I’d really appreciate it if you recommend this post (by clicking the ❤ button) so other people can find it.

Google

Transit

API Protection Requires Both User and App Authentication

How Python Coders Tried to Kill my Supposedly Secure JavaScript API Service

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Whitelists and Indirection Go Together Like Chocolate and Peanut Butter

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Tour of API Underprotection

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

A Tour of API Underprotection

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps