6

in the past I expirmented with Google available api tools, like the Drive and Youtube api's.

The way it works is after you purchase a deveopler account, you are granted to many of Google services through api's, which in order to use, you need a uniuqe api key that is linked to your account, and appended to each of the requests url.

For example:

https://www.googleapis.com/youtube/v3/playlistItems?part=snippet&playlistId=some.playlist.id&key={YOUR_API_KEY}

In the begining I thought it was a smart idea to use the key -> account binding, for instance, if an api key is bypassing the tos, Google can simply ban the account.

But then I found out it is very easy to reverse engineer the authorization key in Android/iOS apps using MITM tools such as Mitmproxy. Using that approach, I managed to find the Youtube official app api key, and many other apps that use those services, so my question is, isn't Google shoot itself in the foot by using the autorization key that way? As apps can still remain anonymous using their services, and even pretend to be other accounts!.

Isn't it a better idea to build sdk which will receive the account key and use it to generate locally a one time key for each request? Of course this could be reverse engineered as well, but it will be much harder...

Improve this question
3
  • 1
    How did you manage to recover API keys using mitmproxy on SSL-protected connections? Via adding a fake root cert to the cert store on the device in question?
    – Out of Band
    Commented Mar 10, 2017 at 22:24
  • @Pascal Yes, I've installed a fake cert on the device, mitmproxy has an extensive documentationon on the topic. Once the ssl communication is visible, it's trivial to retreive the api key...
    – Nadav96
    Commented Mar 10, 2017 at 22:32
  • 2
    Interesting that the Google apps don't use certificate pinning.
    – Awn
    Commented Mar 11, 2017 at 17:47

3 Answers 3

Reset to default
1

If you are on the premium plan, you can get a Google ClientID, which comes with your own private key.

After you sign up for the Google Maps APIs Premium Plan, you'll receive a Welcome letter from Google at the contact email address you provided. Your Welcome letter contains the following important information, so make sure you keep it handy:

  • Project ID
  • Client ID
  • Private cryptographic key for your client ID
  • Google Account

Authentication and authorization

To make requests to our APIs, you must authenticate your application with either an API key or your client ID. In addition, requests for some APIs also require digital signatures.

But you have to be premium :)

Improve this answer
1
  • It's the same issue, maps.googleapis.com/maps/api/js?key= YOUR_API_KEY &callback=initMap which can be found here.
    – Nadav96
    Commented Mar 10, 2017 at 21:20
1

From https://developers.google.com/youtube/registering_an_application:

The API supports API keys and OAuth 2.0 credentials. Create whichever credentials are appropriate for your project:

  1. OAuth 2.0: Your application must send an OAuth 2.0 token with any request that accesses private user data. Your application sends a client ID and, possibly, a client secret to obtain a token. You can generate OAuth 2.0 credentials for web applications, service accounts, or installed applications. See the Creating OAuth 2.0 credentials section for more information.

  2. API keys: A request that does not provide an OAuth 2.0 token must send an API key. The key identifies your project and provides API access, quota, and reports. See the Creating API Keys section for information about creating an API key

What you're seeing is either an OAuth 2.0 key, which is tied to the individual user's account, and can be used to access private user data; or an API key, which can't be used to access private user data, but only for quota/rate limiting and reporting.

Additionally, there are four types of API key:

  • Server keys: you use this on a server, you don't distribute this key with your application
  • Browser keys: Google verifies the usage of this type of token against Referer/Origin header
  • iOS keys and Android keys: Google verifies the usage of this type of token against the application identifiers

MITMing an OAuth 2.0 key only lets you access your own data, so it's not really useful, while MITMing an API key won't let you access user's data, so it's not really useful either. The only thing you can do with MITMing an API key is targeted disruption of your application by maxing out your key's quota or skewing your application's usage report. These are, of course, problems, but it's not something that can be avoided if your application calls YouTube API directly on the client side.

Improve this answer
5
  • Ok, let me be specific, I think the only problem with the api is with android/ios, as server/browser keys can be hidden, or changed quickly for all users. Let's assume I grab the official youtube app api, and starting bombarding the quota usage, the only way google can fight back is by disabling the key right? But by doing so they disable the app access as well! (the app won't function anymore). While Youtube official app is not a good example, as I suspect they don't have a quota limit, other big apps that use any of Google services that offer an api are vulnerable to this issue.
    – Nadav96
    Commented Mar 11, 2017 at 0:02
  • @Nadav96: A client side token for quota limit is a best effort protection, there's nothing you can do to prevent a determined attacker from stealing an API key embedded inside an application, no matter whether it's sent in the URL or the body or even with HMAC signed request. I would think that Google has other forms of quota limit though, like IP Address and per user limiting, so that an attacker is likely to hit those limits before they hit your application's limit. Keep in mind that these quota limits are mostly used to protect the API itself, not your application.
    – Lie Ryan
    Commented Mar 11, 2017 at 0:27
  • As far as Google is concerned, if there's an attacker that abuses your API key, they'd just be happy to cut your application off to maintain service for other applications. If you want to exceed these limits, you can pay Google to request higher quota limit (thus sharing the cost of providing service and handling the abuse), or use a Server API key and wrap your use of YouTube API behind your own server so you can enforce your own restrictions.
    – Lie Ryan
    Commented Mar 11, 2017 at 0:33
  • So what stopping an attacker from targeting Youtube app key? You say they would probably watch ip address and user agents? So what if an attacker launch an botnet attack (through ads for example), and modified the user agent to be exactly like the app? I know that as long as the code runs on the client it will never be fully secure, but wouldn't you agree that mitm the key is a lot more trivial then to reverse engineer the source code? If they offered an sdk rather than an account linked key, they could ssl pin every request made from the sdk, generate one time token for each request etc...
    – Nadav96
    Commented Mar 11, 2017 at 2:18
  • @Nadav96: it's not much more difficult to reverse engineer the key compared to mitm-ing the connection. Even if you obfuscate the code, you can just quite trivially copy-paste the obfuscated request signing code into another application.
    – Lie Ryan
    Commented Mar 11, 2017 at 2:26
0

Apps should have the same problems as web apps, and on web apps, we solve this issue using "proxies". You have a server, typically php, that has your API key and makes request to google using that key when a client hits the server script.

The API's response is logged, redacted, and passed to the requesting client. Your clients never see the API key and you have more log entries covering your app's usage. It also helps you ban certain users without re-keying, and even switch out backend providers while maintaining a uniform response from your client's point of view.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .