Comment sécuriser les appels d'API REST ?

Question

Je suis en train de développer une application web reposante qui utilise un framework web populaire en back-end, par exemple (rails, sinatra, flask, express.js). Idéalement, je veux développer le côté client avec Backbone.js. Comment puis-je laisser mon côté client javascript interagir avec ces appels d'API ? Je ne veux pas que ces appels d'API soient publics et puissent être appelés par curl ou simplement en saisissant le lien sur le navigateur.

Answer 1

En premier lieu, si votre API est utilisée par votre client JS, vous devez supposer qu'elle est publique : Un simple débogueur JS met un attaquant dans une position où il peut envoyer une requête identique octet par octet à partir de l'outil de son choix.

Cela dit, si je lis bien votre question, ce n'est pas ce que vous voulez éviter : Ce que vous ne voulez vraiment pas, c'est que votre API soit utilisée (régulièrement) sans que votre client JS soit impliqué. Voici quelques idées sur la façon, sinon d'imposer, du moins d'encourager l'utilisation de votre client :

• Je suis sûr que votre API possède une sorte de champ d'authentification (par exemple, un hachage calculé sur le client). Si ce n'est pas le cas, jetez un coup d'œil à Cette question de l'OS . Assurez-vous d'utiliser un sel (ou même une clé API) qui est donné à votre client JS sur un session (a.o.t. hardcoded). De cette façon, un consommateur non autorisé de votre API est contraint à beaucoup plus de travail.

• Lors du chargement du client JS, il faut se souvenir de certains en-têtes HTTP (l'agent utilisateur vient à l'esprit) et de l'adresse IP et demander une réauthentification s'ils changent, en utilisant des listes noires pour les suspects habituels. Cela oblige l'attaquant à faire à nouveau ses devoirs de manière plus approfondie.

• Du côté du serveur, rappelez-vous des derniers appels d'API et, avant d'en autoriser un autre, vérifiez si la logique de l'entreprise le permet dès maintenant : Cela prive un attaquant de la possibilité de concentrer plusieurs de ses sessions en une seule session avec votre serveur : En combinaison avec les autres mesures, cela rendra un agresseur facilement détectable.

Je ne l'ai peut-être pas dit avec la clarté nécessaire : Je considère impossible Il n'est pas possible de faire en sorte qu'il soit totalement impossible pour un agresseur de consommer votre service, mais vous pouvez rendre la tâche si difficile qu'elle n'en vaudra peut-être pas la peine.

Answer 2

Vous devez mettre en place un système d'authentification. Une bonne façon de le faire est de définir certaines variables d'en-tête attendues. Par exemple, vous pouvez avoir un appel d'API auth/login qui renvoie un jeton de session. Les appels ultérieurs à votre API s'attendront à ce que le jeton de session soit défini dans une variable d'en-tête HTTP portant un nom spécifique tel que "your-api-token".

Par ailleurs, de nombreux systèmes créent des jetons ou des clés d'accès qui sont attendus (comme youtube, facebook ou twitter) en utilisant une sorte de système de compte api. Dans ces cas, votre client devra les stocker d'une manière ou d'une autre dans le client.

Il suffit alors d'ajouter une vérification de la session dans votre cadre REST et de lancer une exception. Dans la mesure du possible, le code d'état (pour être reposant) devrait être une erreur 401.

Answer 3

Il existe maintenant un standard ouvert appelé "JSON Web Token",

véase https://jwt.io/ & https://en.wikipedia.org/wiki/JSON_Web_Token

JSON Web Token (JWT) est une norme ouverte basée sur JSON (RFC 7519) pour les services suivants créer des jetons qui affirment un certain nombre de revendications. Par exemple, un serveur peut générer un jeton avec l'affirmation "connecté en tant qu'administrateur". et le fournir à un client. Le client pourrait alors utiliser ce jeton pour prouver qu'il est connecté en tant qu'administrateur. Les jetons sont signés par la clé clé du serveur, de sorte que le serveur est en mesure de vérifier que le jeton est légitime. Les jetons sont conçus pour être compacts, sûrs pour les URL et utilisables notamment dans le contexte de l'authentification unique (SSO) des navigateurs Web. Les revendications JWT peuvent être typiquement utilisées pour transmettre l'identité des utilisateurs authentifiés entre une fournisseur d'identité et un fournisseur de services, ou tout autre type de réclamation. Les jetons peuvent également être authentifiés et chiffrés. authentifiés et chiffrés. [3][4]

Answer 4

Excusez-moi @MarkAmery et Eugène, mais c'est incorrect.

Votre application js+html (client) fonctionnant dans le navigateur PEUT être configurée pour exclure non autorisé des appels directs à l'API comme suit :

1. Première étape : Configurez l'API pour qu'elle nécessite une authentification. Le site Le client doit d'abord s'authentifier via le serveur (ou un autre serveur de sécurité). par exemple en demandant à l'utilisateur humain de fournir le bon mot de passe.

Avant l'authentification, les appels à l'API ne sont pas acceptés.

Lors de l'authentification, un "jeton" est renvoyé.

Après l'authentification, seuls les appels API avec le "token" d'authentification seront acceptés.

Bien sûr, à ce stade, seuls les utilisateurs autorisés qui disposent du mot de passe peuvent accéder à l'API, mais s'il s'agit de programmeurs qui déboguent l'application, ils peuvent y accéder directement à des fins de test.

2. Deuxième étape : Configurez maintenant une API de sécurité supplémentaire, qui doit être appelée dans un court laps de temps après que l'application client js+html ait été initialement demandée au serveur. Ce "callback" indiquera au serveur que le client a été téléchargé avec succès. Limitez vos appels REST API pour qu'ils ne fonctionnent que si le client a été demandé récemment et avec succès.

Pour pouvoir utiliser votre API, ils doivent d'abord télécharger le client et l'exécuter dans un navigateur. L'API n'acceptera les appels qu'après avoir reçu le rappel, puis l'entrée de l'utilisateur dans un court laps de temps.

Vous n'avez donc pas à craindre qu'il s'agisse d'un utilisateur non autorisé et sans justificatifs.

(Le titre de la question, "Comment sécuriser les appels d'API REST", et d'après la plupart de ce que vous dites, c'est votre principale préoccupation, et non pas la question littérale de savoir COMMENT votre API est appelée, mais plutôt PAR QUI, n'est-ce pas ?)

Answer 5

1. Définissez une variable SESSION sur le serveur lorsque le client charge pour la première fois votre site Web. index.html (ou backbone.js etc.)

2. Vérifiez cette variable du côté du serveur à chaque appel d'API.

P.S. Ce n'est pas une solution de "sécurité" ! !! Il s'agit simplement d'alléger la charge sur votre serveur afin que les gens n'en abusent pas ou ne fassent pas de "hotlink" de votre API à partir d'autres sites Web et applications.