Wie sichert Google Maps seinen API-Schlüssel? Wie macht man etwas ähnliches?

75

Derzeit müssen Sie bei Google einen API-Schlüssel erstellen, der für die Domain spezifisch ist, von der aus die Karte bereitgestellt wird. Wie setzt Google dies durch? Ich möchte das Gleiche tun.

Ich stelle eine API für meinen Dienst bereit, möchte aber Clients ermöglichen, Aufrufe der API über Javascript und nicht nur vom Server aus einzubetten. Ich könnte es mit nur einem zufälligen Token sichern, aber dies könnte natürlich leicht von jedem gefälscht werden, der sich den Code auf dem Client-Computer ansieht.

Ich habe immer verstanden, dass dieses Konzept nicht möglich ist, aber irgendwie leistet Google gute Arbeit bei der Durchsetzung.

Bearbeiten - Es hört sich so an, als hätte Google doch nichts Erstaunliches getan. Ihre API dient höchstwahrscheinlich nur zur Nachverfolgung und nicht wirklich als Garantie dafür, dass ihre API von der Person mit dem Schlüssel verwendet wird.

Vyrotek
quelle
Ich glaube, ich habe die Antwort gefunden.
Tyler Carter
1
So funktioniert es jetzt: developer.google.com/maps/documentation/javascript/…
dashambles

Antworten:

30

Ich bin mir ziemlich sicher, dass sie die REFERER-URL verwenden, um festzustellen, woher der Anruf kommt. Wenn die Domain nicht mit dem übereinstimmt, was dem Schlüssel zugewiesen ist, handelt es sich um eine ungültige Anforderung.

Als praktisches Beispiel können Sie mit PHP die Domain $_SERVER['HTTP_REFERER']überprüfen, um den Referer zu überprüfen. Wenn die Domain übereinstimmt, geben Sie eine gültige Antwort zurück. Wenn dies nicht der Fall ist, können Sie eine 401 Unauthorized oder eine andere Antwort zurückgeben.

Trevor
quelle
2
Nee. Es ist fälschbar. Ich denke, Google verlässt sich eher auf die IP-Adresse (kann nicht einfach gefälscht werden) und eine DNS-Suche.
Tyler Carter
28
Die API-Adresse für einen Ajax-Aufruf ist die IP-Adresse des Benutzeragenten des Clients, der das Dokument analysiert und das Javascript ausführt. Daher hängt die IP-Adresse der Ajax-Anforderung nicht mit der Dokumentdomäne zusammen. Die einzige Information in der Anfrage, die sich auf die Dokumentdomäne bezieht, ist der Referrer. Natürlich kann der Referrer gefälscht werden. Im Fall der Google-API ist es jedoch die Website, die den Referrer fälschen möchte. Das eigentliche Spoofing kann jedoch nur auf der Clientseite im Browser erfolgen. Spoofing ist also keine so große Bedrohung.
Franci Penov
1
Die Überprüfung erfolgt durch den GMaps-Javascript-Code auf der Clientseite . In diesem Fall müssen Sie den Referrer nicht überprüfen / fälschen ...
Wim
5
Viele gängige Sicherheitslösungen entfernen oder ersetzen den Referer standardmäßig. Werden diese Benutzer daran gehindert, den Dienst zu sehen?
Instine
2
Ein Missbraucher kann den API-Schlüssel fälschen und einen geänderten Verweis verwenden, um das Kontingent eines Unternehmens aus seinem Webbrowser zu stehlen. Es ist auf den Webbrowser (Client) beschränkt. Denken Sie, dass Google die Anzahl der Anfragen, die ein identifizierter Client (eindeutige IP-Adresse) in einem bestimmten Zeitraum stellen kann, in gewisser Weise einschränkt? Dies könnte die Auswirkungen des Kontingentdiebstahls begrenzen.
Nitseg
65

Der API-Schlüssel selbst ist höchstwahrscheinlich ein Einweg-Hash der Domäne, der der Schlüssel zugeordnet ist, und ein Geheimnis, das nur der Google API-Server kennt. Es kann einige andere bekannte (für Google natürlich) Informationen enthalten. Wenn Sie eine Anfrage von dieser Domäne stellen, nimmt der API-Server die Domäne, von der die Anfrage stammt, und führt dieselbe Einweg-Hash-Berechnung durch und vergleicht die beiden Werte.

Bei Ajax-Aufrufen verwenden sie höchstwahrscheinlich den Referrer, um die Domäne des Dokumenthosts abzurufen. Während der Referrer gefälscht werden kann, müssen Sie letztendlich Google Javascript für die Ausführung im Dokument verwenden, um die API verwenden zu können. Zu diesem Zeitpunkt kann dieses Javascript überprüfen, ob das Dokument, das den Ajax-API-Aufruf aufgerufen hat, tatsächlich vom Zielserver stammt. Dies ist natürlich auch fälschbar, vorausgesetzt, Sie haben eine eigene DOM-Implementierung oder eine sofortige Änderung des Skripts. Dieses Spoofing muss jedoch auf der Client-Seite erfolgen, und die Chancen, dass die Website, die die Google-API verwenden möchte, die Client-Software fälschen kann, sind recht gering.

Da die API im Wesentlichen kostenlos ist, hätten sie auch anonymen Zugriff auf ihre API anbieten können. Anscheinend beabsichtigt Google nicht, den unbefugten Zugriff darauf zu schützen, sondern sicherzustellen, dass sie so viele Daten wie möglich über diese Datennutzung sammeln und diese Nutzung mit anderen Daten verknüpfen können, die sie über die Zieldomäne gesammelt haben. Daher würde ich nicht erwarten, dass die Überprüfung des API-Schlüssels viel komplexer ist als oben beschrieben - der ROI für einen fortgeschritteneren Ansatz ist zu niedrig.

Und natürlich gibt es auch Bedenken hinsichtlich möglicher XSS-Angriffe über ihre API. Aber ich glaube nicht, dass ihr API-Schlüssel zu sehr in einen Anti-XSS-Code eingebunden ist.

Franci Penov
quelle
Leider klingt dies nach der vernünftigsten Antwort. Danke für deinen Beitrag.
Vyrotek
2
"Sie hätten anonymen Zugriff anbieten können" - Beachten Sie, dass einige Funktionen durch die Anzahl der Anforderungen pro Tag und den API-Schlüssel (und den Zeitpunkt der Veröffentlichung) begrenzt sind, z. B. die umgekehrte Geolokalisierung.
Piskvor verließ das Gebäude
1
Beachten Sie auch, dass die Verwendung unter HTTPS nicht kostenlos ist.
Arjan
Franci, können Sie im zweiten Absatz näher erläutern, wie das Javascript überprüfen kann, ob das Javascript, das den Ajax-API-Aufruf aufgerufen hat, vom Zielserver stammt?
Govind Rai
3

Wie mein Kommentar sagt:

Der REFERER ist fälschbar, daher ist es wahrscheinlich unwahrscheinlich, dass Google ihn als Mittel zur Überprüfung verwendet. Siehe diesen Wikipedia-Eintrag.

Ich vermute, dass Google wahrscheinlich die IP-Adresse des Anrufers zusammen mit einer DNS-Suche verwendet. DNS ist nicht wirklich fälschbar, da Ihre DNS-Einträge korrekt sein müssen, damit die Website überhaupt zu Ihnen gelangt.

Aber auch das hat seine Probleme, denn wenn ein Server ein Round-Robin-IP-Adress-DNS-Setup verwendet, wird Google bei einer DNS-Suche an eine andere IP-Adresse umgeleitet.

Aus den FAQ

Beachten Sie, dass ein Schlüssel für http://www.mygooglemapssite.com/ nur akzeptiert wird, wenn auf die Site unter dieser Adresse zugegriffen wird. Es wird nicht akzeptiert, wenn auf die Site über eine IP-Adresse (z. B. http://10.1.2.3/ ) oder über einen Hostnamen zugegriffen wird, der unter Verwendung eines DNS-CNAME-Eintrags auf www.mygooglemapssite.com ausgerichtet ist.

Ich vermute, dass möglicherweise der HostHeader verwendet wird, der beim Anfordern der Seite gesendet wird. Dies funktioniert wie gewohnt. Google fordert Sie auf, das API-Skript direkt in die Seite aufzunehmen. Dann hat dieses Skript Zugriff auf die Header für die aktuelle Seite und kann dies zur Überprüfung verwenden.

Meine Vermutung wird durch die Tatsache gestützt, dass es für IP-Adressen oder Aliase nicht funktioniert, was bedeutet, dass es keine DNS-Prüfung durchführt.

Diese Methode kann nicht gefälscht werden, da sie der richtige Header sein muss, um auf die Seite zuzugreifen. Dies bedeutet jedoch, dass Aliase für die Domäne nicht funktionieren.

Dies bedeutet jedoch auch, dass Sie eine Javascript-Bibliothek bereitstellen MÜSSEN, um auf den Code zugreifen zu können, da Sie diese Serverseite meines Erachtens nicht überprüfen können.

Tyler Carter
quelle
Der 'Host'-Header enthält möglicherweise die Adresse, wenn die Seite angefordert wird. Wie kann ich jedoch garantieren, dass der Wert auch an die neue AJAX-Anforderung dieser Seite an meine API übergeben wird? Ich dachte, dies ist im Grunde das, was 'Referrer' enthält, von dem wir wissen, dass es gefälscht werden kann.
Vyrotek
Nun, da SIE den AJAX-Aufruf schreiben (weil Sie die Javascript-Bibliothek bereitgestellt haben), können Sie sicherstellen, dass er gesendet wird.
Tyler Carter
Der Grund, warum Google einen API-Schlüssel benötigen kann, liegt darin, dass sie die Javascript-Bibliothek bereitstellen und dann Javascript auf der Seite ausführen können.
Tyler Carter
1
Richtig, aber jeder kann den auf den Client geladenen Code sehen und Änderungen vornehmen, um eine beliebige Domain-URL zu senden. Es ist also immer noch nicht sicher.
Vyrotek
5
Diese Antwort ist falsch. Wie Arjan gerade sagte, würde der Host-Header für einen Aufruf einer Google-API auf "google.com" gesetzt, also überhaupt keine Verwendung. Die IP-Adresse ist die IP-Adresse des Clients (des Computers, auf dem der Webbrowser ausgeführt wird). Auch keine Verwendung. Der einzige nützliche Header, der von den Browsern kommt, ist der Referrer, der die Website angibt, die der Browser betrachtet. Senden Browser dies immer zu 100% zuverlässig? Kann eine schlechte Person einen einzelnen Browser beschädigen, um einen anderen Referrer zu senden? Ja. Kann eine schlechte Person eine Website erstellen, die alle Browser dazu auffordert? Nein, es funktioniert also als Tracking-Information.
Harry Wood
3

Ich stimme allen Punkten zu , die Franci Penov aufgelistet hat. Ich möchte etwas näher auf die Verwendung des API-Schlüssels eines anderen eingehen. Nehmen wir an, Sie registrieren sich key1bei example.com.

  1. Erster Versuch - Wenn anothersite.comhat <script src="http://www.google.com/jsapi?key=key1">, Google könnte seine Referrer überprüfen (Hash - Schema genannt) , und in diesem Fall gibt es eine Diskrepanz. Wie überwindet ein böser Angreifer dies, da viele Leute erwähnt haben, dass Überweiser gefälscht werden können? Dies gilt hier nicht wirklich. Sicher, Sie könnten beliebige Header senden, wenn Sie die Anfrage stellen, aber wie fälscht der böse Hacker den Referrer für Benutzer anothersite.com? Das ist im Allgemeinen nicht einfach. Es gab alte Versionen von Flash in IE 6, die es Angreifern ermöglichten, beim Erstellen domänenübergreifender Anforderungen beliebige Header festzulegen. Im Allgemeinen funktioniert dies jedoch nicht für Skripte src. Ich bin nicht sicher, ob das enthaltene Javascript eine Validierung durchführt document.location, um dies zu verhindern (wahrscheinlich nicht).

  2. Zweiter Versuch - Ein böser Angreifer kopiert Google Javascript für den API-Schlüssel aus mysite.comder Seitenquelle und bettet dann modifiziertes Javascript ein anothersite.com. Jetzt kann Google nichts mehr überprüfen (die Remote-IP ist der Computer des Nutzers, und Sie oder Google können nicht viel tun).

Wenn Sie also aus irgendeinem Grund Ihren API-Schlüssel geheim halten möchten (ein Grund, warum böswillige Personen Ihren Schlüssel auf die schwarze Liste setzen / blockieren können), binden Sie den Schlüssel nicht über Ihren Server in Client- und Proxy-Anfragen ein (Ihr Anwendungscode hat jetzt den Schlüssel).

beschädigen
quelle
-6

Der Grund dafür ist, dass Sie mit Javascript keine API-Aufrufe durchführen können. Die Browsersicherheit verhindert, dass Javascript irgendwo Anfragen stellt, außer an die Domäne, aus der das Javascript stammt. Aus diesem Grund müssen alle API-Aufrufe von Javascript über Ihren Server weitergeleitet werden, auf dem der API-Schlüssel gespeichert ist (der API-Schlüssel wird von Javascript nie gesehen).

Jeffrey Aylesworth
quelle
2
Es gibt jedoch Möglichkeiten, dies zu umgehen (JSONP). Ich glaube nicht, dass Sie den Anruf nicht tätigen können, sondern die Rücksendung normalerweise nicht bearbeiten können.
Ryan Elkins
Wenn man sich einige Beispiele und insbesondere econym.org.uk/gmap/example_map12.htm ansieht (als gutes Tutorial aufgeführt), scheint es, dass typische Benutzer Schlüssel verfügbar machen , wenn sie src maps api skripten. Das bezogene js überschreibt die Seite (map ist ein Satz von img). Markierungen werden durch Herunterladen von JSON-Daten mit GDownloadUrl () platziert. Dies führt lediglich zu einer XMLHttpRequest und ist somit wieder auf seinem Server. JSONP benötigt Unterstützung von Google Server, oder?
mar
4
Wenn dies wahr wäre, könnte beispielsweise von CDN gehostetes jQuery keine Ajax-Aufrufe an eine andere Domäne als das CDN tätigen.
Arjan