Embed check will always work

[arall]

The endpoint used in https://github.com/ozguralp/gmapsapiscanner/blob/master/maps_api_scanner.py#L28 will always work on valid API keys, even if the key is restricted. Here is why:

If the embed maps are using the basic embed requests, Google will not check restrictions, as the usage of that API is free.

https://www.google.com/maps/embed/v1/place?q=Seattle&key=KEY

But if the advanced map modes are used, then the restrictions apply.

https://www.google.com/maps/embed/v1/search?q=record+stores+in+Seattle&key=KEY

[ozguralp]

Hey,

Good catch on this one! While using the paid API endpoint on the script could be better for a solid PoC, I still cannot observe the restriction difference on both of the endpoints. If the referer restriction exist, both endpoints returning "This IP, site or mobile application is not authorized to use this API key." error, whether it is paid or not. However not sending referer header bypasses this control on both situations. I mentioned about that vulnerability on my latest blog posting https://medium.com/bugbountywriteup/google-maps-api-not-the-key-bugs-that-i-found-over-the-years-781840fc82aa if you didn't read yet. My script is sending requests without referer headers so if the Embed API is active on a key then it is vulnerable whether referer check exists or not.

So in conclusion:

• If referer restriction exist; whether paid api or not, Google servers rejects the request.
• If referer header not sent with the HTML code; either way the it could be abused.
• It also applies to Staticmap and Streetview API's.

Hope this information helps to clarify your thoughts.

[ozguralp]

In addition, you can use the leaked API key by Google mentioned on the blog post to test also for this one with both sending referer headers and not to confirm the behavior.

[arall]

If the referer restriction exist, both endpoints returning "This IP, site or mobile application is not authorized to use this API key."

However not sending referer header bypasses this control on both situations.

If referer restriction exist; whether paid api or not, Google servers rejects the request.

If referer header not sent with the HTML code; either way the it could be abused.

I don't agree. Check the following iframe examples (the key used is the one from Google documentation, as an example):

<!-- Basic mode (free), authorised -->
<iframe src="https://www.google.com/maps/embed/v1/place?q=Seattle&key=AIzaSyD4iE2xVSpkLLOXoyqT-RuPwURN3ddScAI">

<!-- Advanced mode (paid), not authorised -->
<iframe src="https://www.google.com/maps/embed/v1/search?q=record+stores+in+Seattle&key=AIzaSyD4iE2xVSpkLLOXoyqT-RuPwURN3ddScAI">

If we do a request directly to the endpoints:

$ curl -I https://www.google.com/maps/embed/v1/place\?q\=Seattle\&key\=AIzaSyD4iE2xVSpkLLOXoyqT-RuPwURN3ddScAI
> HTTP/2 200 

$ curl -I https://www.google.com/maps/embed/v1/search\?q\=record+stores+in+Seattle\&key\=AIzaSyD4iE2xVSpkLLOXoyqT-RuPwURN3ddScAI
> HTTP/2 403 

As mentioned in the docs I've pointed, the maps/embed/v1/place endpoint is free, and doesn't apply the key referer restrictions.

I've also reached Google Cloud support, and they said:

Maps Support, XXX: I came across this issue before as well and I only initially tried using the Basic mode. And now, I just tested and learned that the restrictions are working for Advanced mode.
Maps Support, XXX: I mean, this is a new learning for me as well so thank you for pointing out :)

[ozguralp]

It seems that you are correct, I conducted the same tests within the ones you sent me however on my first try it was working. Either a cache problem in my web browser (I am %99 sure that it was also working from the Burp Requests/Responses, either I missed something else on that time or something is changed 😄) Anyways thanks for pointing it out, I will add both of the scenarios to the script within both Basic-Advanced (Free-Paid) modes.

[ozguralp]

Hey again,

Just for you to know, I updated script to scan within both basic and advanced Embed API's. I also clarified this issue on my post and mentioned you & gave your credit at the end of the #Vulnerability 1 for this finding. Thanks again for your help!

Ozgur