Comment Google Maps sécurise-t-il sa clé API ? Comment faire quelque chose de similaire ?

Question

Actuellement, Google vous demande de créer une clé API spécifique au domaine à partir duquel la carte sera servie. Comment Google applique-t-il cette règle ? Je veux faire la même chose.

J'expose une API pour mon service mais je veux permettre aux clients d'intégrer des appels à l'API via javascript et pas seulement depuis le serveur. Je pourrais le sécuriser avec un simple jeton aléatoire mais, bien sûr, il pourrait être facilement usurpé par quiconque regarde le code sur la machine du client.

J'ai toujours pensé que ce concept n'était pas possible, mais d'une manière ou d'une autre, Google parvient à le faire respecter.

Edit - Il semble que Google n'a pas vraiment fait quelque chose d'étonnant après tout. Leur API est très probablement juste pour le suivi et pas vraiment pour garantir que leur API est utilisé par la personne avec la clé.

Answer 1

La clé API elle-même est très probablement un hachage à sens unique du domaine auquel la clé est associée et un secret que seul le serveur API de Google connaît. Elle peut contenir d'autres éléments d'information bien connus (de Google, bien sûr). Lorsque vous effectuez une requête à partir de ce domaine, le serveur API prend le domaine d'où provient la requête, effectue le même calcul de hachage à sens unique et compare les deux valeurs.

Pour les appels Ajax, ils utilisent très probablement le référent pour obtenir le domaine de l'hôte du document. Bien que le référent puisse être usurpé, en fin de compte, pour utiliser l'API, vous devez faire en sorte que le javascript de Google s'exécute dans le document. À ce stade, ce javascript peut vérifier que le document qui a invoqué l'appel Ajax API provient bien du serveur cible. Il est bien sûr possible d'usurper cette identité, à condition d'avoir sa propre implémentation DOM ou de modifier à la volée le script. Cependant, cette usurpation doit se produire du côté client et les chances que le site Web qui veut utiliser l'API de Google soit capable d'usurper le logiciel client sont assez faibles.

Notez que puisque l'API est essentiellement gratuite, ils auraient pu également offrir un accès anonyme à leur API. Apparemment, l'intention de Google n'est pas de protéger les accès non autorisés, mais de s'assurer qu'ils peuvent recueillir autant de données que possible sur l'utilisation des données et être en mesure d'associer cette utilisation à d'autres données qu'ils ont recueillies sur le domaine cible. En tant que tel, je ne m'attends pas à ce que la vérification de la clé API soit beaucoup plus complexe que ce que j'ai décrit ci-dessus - le retour sur investissement d'une approche plus avancée est trop faible.

Et bien sûr, il y a aussi le problème des éventuelles attaques XSS via leur API. Mais je ne pense pas que leur clé API soit trop liée à un quelconque code anti-XSS qu'ils ont.

Answer 2

Je suis certain qu'ils utilisent l'URL du REFERER pour déterminer d'où vient l'appel. Si le domaine ne correspond pas à ce qui est assigné à la clé, c'est une requête invalide.

Pour un exemple pratique, en utilisant PHP vous pouvez vérifier le domaine en utilisant $_SERVER['HTTP_REFERER'] pour vérifier le référent. Si le domaine correspond, renvoyez une réponse valide. Si ce n'est pas le cas, vous pouvez renvoyer une réponse 401 non autorisée ou autre.

Answer 3

Comme le dit mon commentaire :

Le REFERER est falsifiable, il est donc peu probable que Google l'utilise comme moyen de vérification. Voir cette entrée wikipédia.

À mon avis, Google utilise probablement l'adresse IP de l'appelant ainsi qu'une recherche DNS. Le DNS ne peut pas vraiment être usurpé, car vos entrées DNS doivent être correctes pour que le site Web puisse vous atteindre.

Mais même cette méthode présente des inconvénients, car si un serveur utilise une configuration DNS à adresse IP circulaire, Google sera redirigé vers une adresse IP différente lors d'une recherche DNS.

Extrait de la FAQ

Notez qu'une clé pour http://www.mygooglemapssite.com/ ne sera accepté que si le site est consulté à partir de cette adresse. Elle ne sera pas acceptée si l'accès au site se fait par adresse IP (ex. http://10.1.2.3/ ) ou par un nom d'hôte qui est aliasé à www.mygooglemapssite.com à l'aide d'un enregistrement DNS CNAME.

Je pense qu'il pourrait utiliser le Host qui est envoyé lors de la demande de la page, ce qui fonctionnerait comme normalement Google vous demande d'inclure son API script directement dans la page. Ensuite, ce script a accès aux en-têtes de la page actuelle et peut l'utiliser pour vérifier.

Ma supposition est étayée par le fait qu'il ne fonctionne pas pour les adresses IP ou les alias, ce qui signifie qu'il ne fait pas de vérification DNS.

Cette méthode ne peut pas être usurpée, car il doit s'agir de l'en-tête correct pour accéder à la page. Cependant, cela signifie que tout alias du domaine ne fonctionnera pas.

Cependant, cela signifie également que vous DEVEZ fournir une bibliothèque Javascript pour accéder au code, car vous ne pouvez pas vérifier cela côté serveur, je crois.

Answer 4

Je suis d'accord avec tous les points que Franci Penov a listé. Je voudrais m'étendre un peu sur l'utilisation de la clé API de quelqu'un d'autre. Supposons que vous vous inscriviez key1 avec example.com .

1. Première tentative - Si anothersite.com a <script src="http://www.google.com/jsapi?key=key1"> Google a pu vérifier son référent (schéma de hachage mentionné) et dans ce cas, il y a un décalage. Comment un attaquant malveillant peut-il surmonter cette difficulté, puisque de nombreuses personnes ont mentionné que le référent peut être usurpé ? Cela ne s'applique pas vraiment ici. Bien sûr, vous pouvez envoyer des en-têtes arbitraires si vous faites la demande, mais comment le pirate malveillant peut-il usurper le référant pour les utilisateurs sur anothersite.com ? En général, ce n'est pas facile. Il y a eu d'anciennes versions de flash sur IE 6 qui permettaient à l'attaquant de définir des en-têtes arbitraires lors des requêtes inter-domaines, mais en général, ce n'est pas faisable pour script. src . Je ne suis pas sûr que le Javascript inclus fasse une quelconque validation de l'information. document.location pour éviter cela (probablement pas).

2. Deuxième tentative - Un attaquant malin copie le Javascript de Google pour obtenir la clé API de mysite.com et intègre ensuite le javascript modifié dans la page de l'utilisateur. anothersite.com . Maintenant, Google ne peut rien vérifier (l'IP distante sera l'ordinateur de l'utilisateur, et il n'y a pas grand-chose que vous ou Google puissiez faire).

Ainsi, si vous souhaitez, pour une raison ou une autre, garder votre clé d'API secrète (une raison, une personne malveillante peut mettre votre clé sur une liste noire/bloquée), alors n'intégrez pas la clé dans les requêtes du client et du proxy via votre serveur (le code de votre application possède maintenant la clé).

Answer 5

La raison pour laquelle cela fonctionne est que vous ne pouvez pas faire d'appels API avec le javascript. La sécurité du navigateur empêche le javascript d'effectuer des requêtes ailleurs que dans le domaine d'où provient le javascript. Pour cette raison, tout appel d'API provenant de javascript doit passer par votre serveur où la clé API est stockée (la clé API n'est jamais vue par javascript).