Est-il sûr d'inclure une clé API dans l'URL d'une demande?
Dernièrement, j'ai vu de nombreuses API conçues comme ceci:
curl "https://api.somewebsite.com/v1/something&key=YOUR-API-KEY"
N'est-il pas élémentaire que le passage d'une clé API dans une chaîne de requête en tant que partie de l'URL n'est pas sécurisé au moins dans HTTP.
Résumé: les URL de capacité sont plus sécurisées que de nombreuses personnes ne le reconnaissent, mais ne conviennent pas à toutes les applications, et nécessitent une attention particulière à l'utilisation .
Ces types d'URL sont communément appelés URL de capacité/URL secrètes.
Il est insensé de parler de sécurité sans spécifier de modèle de menace. Voici quelques exemples qui me viennent à l'esprit:
- 1: Un attaquant passif sur le réseau (écoute indiscrète)
- 2: Un attaquant actif sur le réseau (peut changer les paquets à volonté, mitm, etc.)
- 3: A épaule-surfeur
- 4: Un attaquant disposant d'un accès physique à votre ordinateur/privilèges élevés
- 5: un autre utilisateur de votre ordinateur (privilèges réguliers/accès à distance)
- 6: l'utilisateur lui-même (comme pour protéger une clé API)
En ce qui concerne les attaques réseau (1 et 2), les URL secrètes sont parfaitement sécurisées , à condition d'utiliser HTTPS (c'est 2016, vous ne devriez pas utiliser HTTP) plus!).
Alors que le nom d'hôte d'un serveur est envoyé en texte brut sur le réseau, l'URL réelle est chiffrée avant d'être envoyée au serveur - car elle fait partie de la demande GET, qui ne se produit que après la prise de contact TLS .
En ce qui concerne le surf à l'épaule (3), une URL secrète avec suffisamment d'entropie est raisonnablement sécurisée contre une attaque occasionnelle · À titre d'exemple, je vais donner un google URL des documents:
https://docs.google.com/document/d/5BPuCpxGkVOxkjTG0QrS-JoaImEE-kNAi0Ma9DP1gy
Bonne chance en vous souvenant qu'en passant devant un écran de collègue!
De toute évidence, si votre attaquant a un appareil photo et peut prendre une photo sans être remarqué, c'est une tout autre affaire - vous ne devez pas utiliser une URL secrète dans cette situation. Vous pouvez atténuer l'attaque en effectuant une redirection HTTP loin de l'URL secrète, elle n'est donc à l'écran que quelques secondes
Concernant un attaquant disposant de privilèges élevés sur votre ordinateur (4), une URL secrète n'est pas moins sécurisée qu'un mot de passe long ou même un certificat TLS côté client - car tous ces éléments sont en fait complètement précaires, et il n'y a pas grand-chose que vous puissiez faire à ce sujet.
En revanche, un attaquant disposant de privilèges réguliers (5) ne devrait pas non plus être en mesure d'apprendre l'URL secrète tant que vous respectez les bonnes pratiques de sécurité pour votre système d'exploitation . Vos fichiers (en particulier l'historique du navigateur) ne doivent pas être lisibles par les autres utilisateurs.
Pour protéger les clés API (6, ce qui était le point de cette question), une URL secrète est également non moins sécurisée qu'un autre mécanisme (tel qu'un AJAX POST ) . Toute personne ayant une utilisation pour une clé API saura comment utiliser le mode de débogage du navigateur pour obtenir la clé.
Il n'est pas raisonnable d'envoyer un secret à quelqu'un et de s'attendre à ce qu'il ne le regarde pas!
Certaines personnes ont posé des questions sur les risques côté serveur.
Il n'est pas raisonnable de traiter les risques côté serveur par la modélisation des menaces; du point de vue de l'utilisateur, vous devez vraiment traiter le serveur comme tiers de confiance , comme si votre adversaire a un accès réseau interne côté serveur, il n'y a vraiment rien que vous puissiez faire (un peu comme un privilégié l'attaquant sur l'ordinateur du client, c'est-à-dire le modèle de menace 4 ci-dessus).
Au lieu de modéliser les attaques, je décrirai les risques courants d'exposition secrète non intentionnelle .
Le problème le plus courant avec l'utilisation d'URL secrètes côté serveur est que le serveur HTTP et les proxys inverses conservent des journaux, et l'URL est très souvent incluse .
Une autre possibilité est que les URL secrètes pourraient être générées de manière prévisible - soit à cause d'une implémentation imparfaite, soit non sécurisée PRNG , ou donnant une entropie insuffisante lorsque l'ensemencement .
De nombreuses mises en garde doivent également être prises en compte lors de la conception d'un site utilisant des URL secrètes. Cette page par W3C TAG couvre beaucoup d'entre eux.
En pratique, pour les sites avec du contenu dynamique, il est assez difficile de tout faire en toute sécurité - Google et Dropbox l'ont bâclé dans le passé, comme mentionné sur ce réponse
Enfin, les URL secrètes présentent quelques avantages par rapport aux autres méthodes d'authentification :
- Ils sont extrêmement faciles à utiliser (cliquez simplement sur le lien, au lieu de saisir votre e-mail et votre mot de passe)
- Ils ne nécessitent pas que le serveur/service stocke en toute sécurité les informations d'identification d'utilisateur sensibles
- Ils sont facilement partageables sans risques, contrairement au partage de votre mot de passe (que vous réutilisez pour 50 autres sites).
Cela dépend de la façon dont cette API doit être utilisée et du type de données auquel elle accède. Un élément qui accède à Google Maps (par exemple) présente un risque beaucoup plus faible qu'un élément accédant aux données bancaires.
Évidemment, un appel comme celui-ci dans le code côté client n'est pas sécurisé, l'utilisateur peut facilement apprendre votre clé API.
Si l'appel d'API est effectué de serveur à serveur, c'est moins un problème.
L'utilisation de HTTP laisserait la connexion ouverte à l'écoute, HTTPS supprime ce problème.
Un autre problème avec les clés dans l'URL est que l'URL complète se retrouve dans les fichiers journaux. Cela élargit la surface d'attaque de l'application, car il y a maintenant plus d'endroits pour rechercher la clé.
Pour répondre à votre question, ce n'est pas que la transmission de clés dans l'URL est intrinsèquement non sécurisée, mais plutôt moins sécurisée que les alternatives et pas la meilleure pratique. En supposant que l'API n'accède pas à quelque chose de sensible, la connexion est via HTTPS et l'appel est effectué de serveur à serveur, il devrait être `` assez bon '' pour les services à faible risque.
Ce n'est pas une bonne idée de passer des secrets en tant que paramètres GET en général. J'ai compilé une liste sur mon blog il y a quelques temps sur les problèmes de sécurité potentiels:
Les secrets peuvent être divulgués à d'autres parties comme suit:
Depuis votre ordinateur/smartphone
Côté serveur
- Journaux du serveur Web
- Services d'agrégation de journaux tels que SIEM, Elasticsearch, Splunk
- Fichiers journaux indexés par les moteurs de recherche (pertinent Google dork )
- Journaux de proxy inverse
À des tiers
- Journaux proxy (par exemple dans un environnement d'entreprise)
- Services de génération de rapports d'exception tels que Rollbar ou Sentry
- Autres sites Web via l'en-tête
Referer - Un ami, si l'URL est partagée dans un e-mail ou un message instantané
- Fellow locataires dans un cloud public
Certains d'entre eux ne s'appliquent pas aux requêtes Ajax, mais ymmv
Je me demande pourquoi personne ne mentionne explicitement le risque de fixation de session et de vulnérabilités CSRF. Bien sûr, vous pouvez les atténuer en ajoutant des jetons CSRF et implémenter une gestion de session sécurisée, mais cela implique que vous avez réellement le contrôle sur le code pertinent.
Puisque cette question a le titre A secret in a URL certaines personnes pourraient conclure qu'il est suffisant de mettre en œuvre des mesures d'atténuation au lieu de le considérer comme un vecteur d'attaque possible qui peut être évité.