Google Maps API-Schlüssel gratis nutzen

Die Verwendung eines Google-API-Schlüssel kann auf eine konfigurierbare Menge von Host- und Domain-Namen eingeschränkt werden. Schützt das vor Missbrauch des Schlüssels durch Dritte? Nein, nicht wirklich.

Zwei Bemerkungen vorweg: Erstens will ich selbstverständlich niemanden ermuntern, API-Schlüssel anderer zu verwenden. Aber zahlende Google-Kunden sollten dafür sensibilisiert werden, dass Google nicht dazu in der Lage ist zu garantieren, dass die Schlüssel nur bestimmungsgemäß Verwendung finden.

Zweitens sei darauf hingewiesen, dass das Problem keineswegs spezifisch für Google Maps ist. Es ist noch nicht einmal spezifisch für Google, da andere Anbieter die gleiche Logik verwenden. Google Maps ist lediglich ein gutes Beispiel, weil es auf so vielen Websites verwendet wird.

Wie wird der Schlüssel verwendet?

Der Schlüssel wird als URI-Parameter übertragen, wenn das JavaScript vom Server abgerufen wird. Beispiel:

<script src="https://maps.googleapis.com/maps/api/js?key=DEIN_KEY&libraries=places,geometry&callback=initAutocomplete"
        async defer></script>

Der Schlüssel ist also mitnichten ein Gehheimnis. Er ist notwendigerweise im Quelltext der Webseite sichtbar.

Nicht nur das, bequemerweise lassen sich solche Schlüssel auch in großer Anzahl mit einem Web-Crawler im Netz sammeln. Dabei lässt sich gleich auch noch feststellen, welche API-Teile ("places", "geometry", "drawing", "visualization") mit dem Schlüssel verwendet werden können.

Wie funktioniert der Schutz?

Welche Host- und Domainnamen einen Schlüssel "verwenden" dürfen, lässt sich konfigurieren. Verwenden bedeutet hierbei, dass API-Requests von einem "Origin" (einer Web-Site) gemacht werden, die auf einem der erlaubten Hostnamen (nicht Hosts!) gehostet wird.

Woher jedoch erhält der JavaScript-Code, den Origin der Seite? Vom Browser! Und das bedeutet, dass diese Information nicht vertrauenswürdig ist. Der Source-Code des Browsers kann zum Beispiel so gepatcht sein, dass falsche Informationen übergeben werden.

Der Exploit

Aber man muss nicht gleich den Browser patchen und neu kompilieren. Es geht auch viel einfacher.

Die meisten Schlüssel sind nämlich vermutlich für die Origins "localhost" und/oder "127.0.0.1" nutzbar, damit lokal entwickelt werden kann. Es lohnt sich jedenfalls, das einmal auszuprobieren. Entwickelt man die eigene Web-Applikation also auf "localhost" (und wer macht das nicht?), tut es vermutlich praktisch jeder API-Key, den man findet. Das ist also der kostenlose Plan zu Entwicklungszwecken, den Google nicht anbietet.

Aber selbst, wenn ein Schlüsselinhaber schlau sein will und für die Produktivumgebung einen Schlüssel erzeugt, der nicht mit dem Loopback-Interface benutzt werden soll, muss sich der Trittbrettfahrer keine Sorgen machen. Er editiert einfach /etc/hosts:

127.0.0.1 www.mein-ex-arbeitgeber.de

Und schon sind wir wieder im Spiel. Die lokale Applikation ist jetzt auf www.mein-ex-arbeitgeber.de gehostet.

Weshalb kein IP-basierter Schutz?

Eine Sekunde selber nachdenken ...

JavaScript kann nicht die IP-Adresse des Servers, der den Code hostet herausfinden. Und aus Googles Sicht hilft das auch überhaupt nicht. Wenn der Schlüssel, der für www.mein-ex-arbeitgeber.de gedacht ist, auf der lokalen Maschine missbraucht wird, sind die API-Aufrufe nicht von denen zu unterscheiden, die aus Code auf der echten IP von www.mein-ex-arbeitgeber.de gemacht werden.

Natürlich kann Google Rate-Limiting einsetzen, und ich bin mir sicher, dass sie es auch tun. Das ist allerdings nur ein Pflaster, keine echte Lösung.

Und was hat man davon?

Man kann also die Web-App für das neue Projekt www.meine-eigene-webbude.de mit dem API-Schlüssel von www.mein-ex-arbeitgeber.de entwickeln. Aber sobald die Applikation auf den öffentlich zugänglichen Server www.meine-eigene-webbude.de aufgespielt wird, fällt man hart auf den Boden der Tatsachen. Die Entwickler können natürlich ihre Browser patchen oder /etc/hosts editieren, aber die Besucherinnen und Besucher der Site tun das nicht, und die API-Calls schlagen deshalb fehl.

Stimmt. Aber nur zum Teil. Denn man kann die Requests natürlich einfach durch einen kleinen Proxy auf dem eigenen Server routen, und man ist doch wieder im Spiel. Diesen Proxy mit Express zu schreiben, dürfte für halbwegs begabte Web-Entwickler keine Herausforderung darstellen.

Die Rechtslage (in Deutschland)

Den Schlüssel anderer Leute zu verwenden, verstößt vermutlich gegen Googles Nutzungsbedingungen. Na und? Ein Angreifer kann und wird Google Maps nutzen, ohne diesen Bedingungen zuzustimmen. Wo kein Vertrag, da kein Vertragsbruch.

Aber kann das Opfer den Angreifer für den Schaden in Haftung nehmen? Jeder einzelne API-Call kostet, und somit kann ein beträchtlicher Schaden entstehen.

Voraussetzung dafür wäre, dass der Angreifer widerrechtlich handelt, also einen Vertrag oder ein Gesetz bricht.

Einen Vertrag hat der Angreifer weder mit Google noch mit dem Opfer geschlossen. Und was ist mit einem Gesetzesbruch? Hier käme Computerbetrug in Frage. Computerbetrug stellt die Verwendung unrichtiger oder unvollständiger Daten oder die unbefugte Verwendung von Daten unter Strafe.

Ob der beschriebene Trick diesen Tatbestand erfüllt, oder damit ein anderes Gesetz gebrochen wird, kann ich nicht mit Bestimmtheit sagen, und will es eigentlich auch gar nicht, denn ich möchte niemanden ermuntern, das Vermögen anderer auf diese Art und Weise zu schädigen. Aber mein Eindruck ist, dass eine Argumentationskette, mit der sich der Sachverhalt unter diesen Tatbestand subsumieren ließe, etwas weit hergeholt wäre.

Andererseits bleibt es dem Opfer natürlich unbenommen, Google für den erlittenen Schaden in Haftung zu nehmen, indem für die erschlichenen API-Calls einfach nicht bezahlt wird. Nur wie kann das Opfer den Missbrauch herausfinden, wenn noch nicht einmal die IPs, von den die Aufrufe gemacht wurden, bekannt sind? Und selbst wenn Google sie herausgäbe, wie sollte ein aktiver Missbrauch des API-Schlüssels von Fällen unterschieden werden, in denen User aus Spaß oder purer Boshaftigkeit auf F5 herumtrillern?

Googles Position

Schon vor Wochen habe ich über die Google Cloud Platform Console um eine Stellungnahme gebeten. Auf eine Reaktion warte ich indes noch immer.

Zur Entwarnung ist hier der Hinweis angebracht, dass hier von Diensten die Rede ist, für die Preise im Mikro-Cent-Bereich pro Request aufgerufen werden, und es ist anzunehmen, dass Google einen Exploit im großen Stil abwehren kann. Dennoch bleibt ein ungutes Gefühl, dass hier ein Billingmodell zur Anwendung kommt, dass durch und durch intransparent und zudem angreifbar ist.

Schlussfolgerung

Die Standard-Methode, mit der JavaScript-API-Schlüssel geschützt werden, ist bestenfalls fragil zu nennen. Angreifer, die eine im Vergleich zum Opfer kleine Site betreiben, haben sehr wenig zu fürchten.