Comment sécuriser les appels de L'API REST?
je développe l'application web restful qui utilise un cadre web populaire sur le backend, par exemple (rails, sinatra, flask, express.js). Idéalement, je veux développer le côté client avec L'épine dorsale.js. Comment puis-je laisser seulement mon côté client javascript interagir avec ces appels API? Je ne veux pas que ces appels API soient publics et appelés par curl ou simplement en entrant le lien sur le navigateur.
6 réponses
en premier lieu, si votre API est consommée par votre client JS, vous devez supposer qu'elle est publique: un débogueur js simple met un attaquant en position, où il peut envoyer une requête byte-for-byte identique à partir d'un outil de son choix.
cela dit, si j'ai lu votre question correctement, ce n'est pas ce que vous voulez éviter: Ce que vous ne voulez vraiment pas à passer, c'est que votre API est consommé sur une base régulière) sans votre JS client. Voici quelques idées sur la façon de ne pas appliquer, puis au moins encourager l'utilisation de votre client:
-
je suis sûr que votre API a une sorte de champ d'authentification (par exemple hachage calculé sur le client). Si non, jetez un oeil à cette question SO . Assurez-vous que vous utilisez un sel (ou même une clé API) qui est donné à votre client JS sur une session base (A. O. T. hardcoded). De cette façon, un consommateur non autorisé de votre API est forcé beaucoup plus de travail.
-
lors du chargement du client JS, souvenez-vous de quelques en-têtes HTTP (l'agent utilisateur vient à l'esprit) et de l'adresse IP et demandez une réauthentication s'ils changent, en utilisant des listes noires pour les suspects habituels. Cela oblige un attaquant à faire ses devoirs de manière plus approfondie à nouveau.
-
côté serveur, souvenez-vous des derniers appels API, et avant d'en autoriser un autre, vérifiez si la logique d'entreprise permet le nouveau en ce moment: ceci nie à un attaquant la capacité de concentrer plusieurs de ses sessions en une seule session avec votre serveur: en combinaison avec les autres mesures, cela rendra un agresseur facile à détecter.
Je n'ai peut-être pas dit cela avec la clarté nécessaire: je considère qu'il impossible de rendre tout à fait impossible pour un agresseur de consommer votre service, mais vous pouvez le rendre si difficile, il pourrait ne pas être la peine tracas.
vous devez implémenter une sorte de système d'authentification. Une bonne façon de gérer cela 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 token de session. Les appels ultérieurs à votre API s'attendront à ce qu'un token de session soit défini dans une variable D'en-tête HTTP avec un nom spécifique comme "your-api-token".
alternativement beaucoup de systèmes créent des jetons d'accès ou des clé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 magasin, d'une certaine manière le client.
alors il s'agit simplement d'ajouter un chèque pour la session dans votre cadre de repos et de jeter une exception. Si possible, le code d'état (restful) serait une erreur 401.
il y a un standard ouvert maintenant appelé "JSON Web Token",
voir https://jwt.io/ & https://en.wikipedia.org/wiki/JSON_Web_Token
JSON Web Token (JWT) est un standard ouvert basé sur JSON (RFC 7519) pour créer des jetons qui affirment un certain nombre de revendications. Par exemple, un le serveur peut générer un token qui a la réclamation "enregistré en tant qu'administrateur" et fournir ça à un client. Le le client pourrait alors utiliser ce jeton pour prouver qu'ils sont connectés en tant qu'administrateur. Les jetons sont signés par le serveur de clés, de sorte que le serveur est en mesure de vérifier que le jeton est légitime. Les tokens sont conçus pour être compacts, sécurisés et utilisables en particulier dans le contexte de connexion unique du navigateur Web (SSO). JWT réclamations être généralement utilisé pour transmettre l'identité des utilisateurs authentifiés entre un fournisseur d'identité et un fournisseur de service, ou tout autre type de demandes tel que requis par les entreprises processus.[1][2] Les jetons peuvent également être authentifiés et chiffrés.[3] [4]
Excusez-moi @ MarkAmery et Eugene, mais c'est incorrect.
votre application js+html (client) fonctionnant dans le navigateur peut être configurée pour exclure non autorisé appels directs à L'API comme suit:
- première étape: Configurer l'API pour exiger l'authentification. Le client doit d'abord s'authentifier via le serveur (ou un autre serveur de sécurité) en demandant par exemple utilisateur humain pour fournir le mot de passe correct.
avant authentification les appels à L'API ne sont pas acceptés.
pendant l'authentification un" token " est retourné.
après authentification seuls les appels API avec le" token " d'authentification seront acceptés.
bien sûr, à ce stade, seuls les utilisateurs autorisés qui ont le mot de passe peuvent accéder à L'API, bien que s'ils sont programmeurs déboguant l'application, ils peuvent y accéder directement à des fins de test.
- deuxième étape: maintenant configurer une API de sécurité supplémentaire, qui doit être appelée dans un court délai après que le client JS+HTML app a été initialement demandé à partir du serveur. Ce "rappel" indiquera au serveur que le client a été téléchargé avec succès. Limitez vos appels de L'API REST pour qu'ils ne fonctionnent que si le client a été demandé récemment et avec succès.
maintenant, pour utiliser votre API, ils doivent d'abord télécharger le client et l'exécuter dans un navigateur. Ce n'est qu'après avoir reçu avec succès le rappel, puis l'entrée de l'utilisateur dans un court laps de temps, que l'API acceptera les appels.
donc vous n'avez pas à vous inquiéter qu'il puisse s'agir d'un utilisateur non autorisé sans justificatifs d'identité.
(Le titre de la question: "Comment puis-je obtenir le REPOS des appels d'API", et de la plupart de ce que vous dites, c'est votre principale préoccupation, et pas la question littérale de la façon dont votre API est appelée, mais plutôt par qui, correct?)
-
Paramétrez une var de SESSION sur le serveur lorsque le client charge pour la première fois votre
index.html(oubackbone.jsetc.) -
Vérifiez cette var du côté du serveur pour chaque appel API.
P. S. ce n'est pas une solution" de sécurité"!!! Ceci est juste pour alléger la charge sur votre serveur de sorte que les gens ne l'abusent pas ou "hotlink" votre API à partir d'autres sites Web et applications.
Voici ce que je fais:
-
Sécurisez L'API avec un en-tête HTTP avec des appels tels que X-APITOKEN:
-
utiliser les variables de session en PHP. Avoir un système de connexion en place et enregistrer le token de l'utilisateur dans les variables de session.
-
Appel code JS avec Ajax, PHP et utiliser la variable de session avec curl pour appeler l'API. De cette façon, si la variable session n'est pas définie, elle won't call et le code PHP contient le Token D'accès à L'API.