Should We Reconsider Using Google Places SDK?
An early assessment of Google Places SDK from an App developer perspective.
If you own mobile apps that have features for users to enter their locations, then you might be using Google Places SDK. In today’s environment, where food deliveries, logistics, and public transportations are essential for our day to day necessities, Google Places SDK is indeed an integral part of the user journey.
As one of the top map data providers, Google tries to make it easier for developers to use their Places API. Developers can easily install the Google Places SDK and start using Places API with only a few lines of code.
What about security?
Apparently, after some research, we found out that implementing Google Places SDK is not entirely secure. Places SDK makes a simple API call to the Google Places API that hackers can easily listen to with MITM Proxy Injection.
The MITM or so-called “Man-in-the-middle” is a type of attack where hackers’ main goal is either stealing information or editing information. The hacker installs an active eavesdropping proxy between the app and the backend server. In this case, the hacker would pretend to be your user and perform MITM attack to steal 3rd party API key, copyrighted content, or any of your hardcoded sensitive information.
Another vulnerability is that MITM Proxy Injection is quite easy to perform in most Android or iOS applications, especially if your app never had a security audit. This article explains how easy it is to inject MITM to an Android app https://bird.ac/injecting-mitm-proxy-on-compiled-android-apk/. In iOS, it is even easier to insert a MITM proxy. You need to install the custom SSL certificate and set your trust setting.
Let’s say if someone happens to tamper your app and eavesdrop your Google Places API request & response, they will see this payload below.
All your security value to authorize a Places API calls are there. With that, they can implement Google Place API on their website or mobile apps while you have to pay their bill.
Google Play has a feature to warn us if we have a hardcoded key inserted in our code. But without SSL pinning built-in in their Place SDK, it will still be useless no matter how much you try to secure your API Key. Every time you use the Places SDK, there will be a risk of an eavesdropped connection revealing sensitive information to other parties.
So what can we do to prevent it from happening?
In the first option, instead of using Places SDK, you can build a new service that proxy the Places SDK and protect it with authentication. By doing so, you can also implement a logging mechanism and API calls spamming prevention baked to your service. The downside to this alternative is that you need to spend some server resources and backend efforts to build it. However, it is still more advantageous to having your key stolen.
If you are not able to implement the first solution, these actions below could be a workaround:
1. Implement SSL Pinning
Typically when a MITM attack happens, the MITM proxy needs to tamper the SSL certificate with their custom certificate to eavesdrop the HTTPS connection payload. To avoid this, we can implement an SSL pinning mechanism that can detect and give us a signal every time a MITM proxy is active. Accordingly, we can instantly abort all activities that use Places SDK.
2. APK Tampering Protection for Android App
For Android, we can avert app tampering by checking app signature value and close the application if it shows a different key signature with your Keystore. Even though the attacker still might be able to remove our protection and reinstall the code, we give them enough complexity to do so.
Although there could be another security hole that will enable MITM, it is still better to implement these two steps than with zero protection.
Summing-up
Your Places API key is never secure if you put it hardcoded in your app. A simple MITM attack can crack your app open and leaking your API key to hackers. While we wait for Google to release Places SDK with built-in SSL pinning, we can implement SSL pinning and APK tampering ourselves as interim protection. Still, the best protection is to never store the API key in your app in the first place.
