Meilleures pratiques pour sécuriser une API / un service Web REST [fermé]

Lors de la conception d'une API ou d'un service REST, existe-t-il des meilleures pratiques établies pour gérer la sécurité (authentification, autorisation, gestion des identités)?

Lorsque vous créez une API SOAP, vous avez WS-Security comme guide et de nombreuses publications existent sur le sujet. J'ai trouvé moins d'informations sur la sécurisation des points de terminaison REST.

Bien que je comprenne que REST n'a intentionnellement pas de spécifications analogues à WS- *, j'espère que les meilleures pratiques ou les modèles recommandés ont émergé.

Toute discussion ou tout lien vers des documents pertinents serait très apprécié. Si cela est important, nous utiliserions WCF avec des messages sérialisés POX / JSON pour nos API / services REST construits à l'aide de la v3.5 du .NET Framework.

Comme l'a dit tweakt, Amazon S3 est un bon modèle avec lequel travailler. Leurs signatures de demande ont certaines fonctionnalités (telles que l'incorporation d'un horodatage) qui aident à se prémunir contre la relecture des demandes accidentelles et malveillantes.

La bonne chose à propos de HTTP Basic est que pratiquement toutes les bibliothèques HTTP le prennent en charge. Vous devrez, bien sûr, exiger SSL dans ce cas, car l'envoi de mots de passe en clair sur le net est presque universellement une mauvaise chose. De base est préférable à Digest lors de l'utilisation de SSL car même si l'appelant sait déjà que les informations d'identification sont requises, Digest nécessite un aller-retour supplémentaire pour échanger la valeur nonce. Avec Basic, les appelants envoient simplement les informations d'identification la première fois.

Une fois que l'identité du client est établie, l'autorisation n'est plus qu'un problème de mise en œuvre. Cependant, vous pouvez déléguer l'autorisation à un autre composant avec un modèle d'autorisation existant. Encore une fois, la bonne chose à propos de Basic ici est que votre serveur se retrouve avec une copie en clair du mot de passe du client que vous pouvez simplement transmettre à un autre composant de votre infrastructure si nécessaire.

Il n'y a pas de normes pour REST autres que HTTP. Il existe des services REST bien établis. Je vous suggère de jeter un œil à eux et de vous faire une idée de leur fonctionnement.

Par exemple, nous avons emprunté beaucoup d'idées au service S3 REST d'Amazon lors du développement du nôtre. Mais nous avons choisi de ne pas utiliser le modèle de sécurité plus avancé basé sur les signatures de demande. L'approche la plus simple est l'authentification HTTP de base sur SSL. Vous devez décider ce qui fonctionne le mieux dans votre situation.

Aussi, je recommande fortement le livre RESTful Web Services d'O'reilly. Il explique les concepts de base et fournit quelques meilleures pratiques. Vous pouvez généralement prendre le modèle fourni et le mapper à votre propre application.

Vous pouvez également jeter un œil à OAuth , un nouveau protocole ouvert pour l'autorisation basée sur des jetons ciblant spécifiquement les API http.

Il est très similaire à l'approche adoptée par flickr et rappelez-vous les apis de lait "repos" (pas nécessairement de bons exemples d'apis reposants, mais de bons exemples de l'approche basée sur les jetons).

Il y a une grande liste de contrôle trouvée sur Github :

Authentification

• Ne réinventez pas la roue dans l'authentification, la génération de jetons et le stockage des mots de passe. Utilisez les normes.

• Utiliser Max Retryet emprisonner les fonctionnalités de la connexion.

• Utilisez le cryptage sur toutes les données sensibles.

JWT (jeton Web JSON)

• Utilisez une clé aléatoire compliquée (JWT Secret) pour rendre le forçage brutal très difficile.

• N'extrayez pas l'algorithme de la charge utile. Forcer l'algorithme dans le backend (HS256 ou RS256).

• Faites en sorte que l'expiration des jetons ( TTL, RTTL) soit aussi courte que possible.

• Ne stockez pas de données sensibles dans la JWTcharge utile, elles peuvent être décodées facilement.

OAuth

• Validez toujours redirect_uricôté serveur pour n'autoriser que les URL en liste blanche.

• Essayez toujours d'échanger du code et non des jetons (ne pas autoriser response_type=token).

• Utilisez le paramètre d'état avec un hachage aléatoire pour empêcher CSRFle OAuthprocessus d'authentification.

• Définissez la portée par défaut et validez les paramètres de portée pour chaque application.

Accès

• Limitez les demandes (limitation) pour éviter les attaques DDoS / force brute.

• Utilisez HTTPS côté serveur pour éviter le MITM (Man In The Middle Attack)

• Utilisez l'en- HSTStête avec SSL pour éviter une attaque SSL Strip.

Contribution

• Utilisez la méthode HTTP appropriée en fonction de l'opération: GET(lecture), POST(création), PUT/PATCH(remplacement / mise à jour) et DELETE(pour supprimer un enregistrement), et répondez 405 Method Not Allowedsi la méthode demandée n'est pas appropriée pour la ressource demandée.

• Valider type de contenu sur demande en- Accepttête (négociation de contenu) pour permettre uniquement le format pris en charge (par exemple application/xml, application/jsonetc.) et d'y répondre avec une 406 Not Acceptableréponse si ne correspond pas.

• Valider content-typedes données affichées que vous acceptez (par exemple application/x-www-form-urlencoded, multipart/form-data, application/json, etc.).

• Validez les entrées utilisateur pour éviter les vulnérabilités courantes (par exemple XSS, injection SQL, exécution de code à distance, etc.).

• N'utilisez pas de données sensibles (informations d'identification, mots de passe, jetons de sécurité ou clés API) dans l'URL, mais utilisez l'en- Authorizationtête standard .

• Utilisez un service API Gateway pour activer la mise en cache, les Rate Limitpolitiques (par exemple, Quota, Spike Arrest, Concurrent Rate Limit) et déployer dynamiquement les ressources des API.

En traitement

• Vérifiez si tous les points de terminaison sont protégés derrière l'authentification pour éviter un processus d'authentification interrompu.

• L'ID de ressource propre à l'utilisateur doit être évité. Utilisez / moi / commandes au lieu de / utilisateur / 654321 / commandes.

• Ne pas incrémenter automatiquement les ID. Utilisez plutôt l'UUID.

• Si vous analysez des fichiers XML, assurez-vous que l'analyse d'entité n'est pas activée pour éviter XXE (attaque d'entité externe XML).

• Si vous analysez des fichiers XML, assurez-vous que l'expansion d'entité n'est pas activée pour éviter la bombe de Billion Laughs / XML via une attaque d'expansion exponentielle d'entité.

• Utilisez un CDN pour les téléchargements de fichiers.

• Si vous avez affaire à une énorme quantité de données, utilisez Workers et Queues pour traiter autant que possible en arrière-plan et renvoyer rapidement la réponse pour éviter le blocage HTTP.

• N'oubliez pas de désactiver le mode DEBUG .

Production

• Envoyer l'en- X-Content-Type-Options: nosnifftête.

• Envoyer l'en- X-Frame-Options: denytête.

• Envoyer l'en- Content-Security-Policy: default-src 'none'tête.

• Retirer les en- têtes d' empreintes digitales - X-Powered-By, Server, X-AspNet-Versionetc.

• Forcer content-typepour votre réponse, si vous revenez, application/jsonle type de contenu de votre réponse est application/json.

• Ne renvoyez pas de données sensibles comme les informations d'identification, les mots de passe, les jetons de sécurité.

• Renvoyez le code d'état approprié en fonction de l'opération terminée. (par exemple 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed, etc.).

Je suis un peu surpris que SSL avec les certificats clients n'ait pas encore été mentionné. Certes, cette approche n'est vraiment utile que si vous pouvez compter sur la communauté des utilisateurs identifiés par des certificats. Mais un certain nombre de gouvernements / entreprises les remettent à leurs utilisateurs. L'utilisateur n'a pas à se soucier de créer une autre combinaison nom d'utilisateur / mot de passe, et l'identité est établie sur chaque connexion afin que la communication avec le serveur puisse être entièrement sans état, aucune session utilisateur n'est requise. (Pour ne pas impliquer que toutes / toutes les autres solutions mentionnées nécessitent des sessions)

Tout le monde dans ces réponses a ignoré le véritable contrôle d'accès / autorisation.

Si, par exemple, vos API / services Web REST concernent le POST / OBTENIR des dossiers médicaux, vous pouvez définir une politique de contrôle d'accès sur qui peut accéder aux données et dans quelles circonstances. Par exemple:

• les médecins peuvent obtenir le dossier médical d'un patient avec lequel ils entretiennent une relation de soins
• personne ne peut publier des données médicales en dehors des heures de pratique (par exemple 9 à 5)
• les utilisateurs finaux peuvent obtenir les dossiers médicaux qu'ils possèdent ou les dossiers médicaux des patients dont ils sont le tuteur
• les infirmières peuvent METTRE À JOUR le dossier médical d'un patient qui appartient à la même unité que l'infirmière.

Afin de définir et de mettre en œuvre ces autorisations à granularité fine, vous devrez utiliser un langage de contrôle d'accès basé sur des attributs appelé XACML, le langage de balisage de contrôle d'accès eXtensible.

Les autres normes ici concernent les suivantes:

• OAuth: id. fédération et délégation d'autorisation, par exemple laisser un service agir en mon nom sur un autre service (Facebook peut publier sur mon Twitter)
• SAML: fédération d'identité / SSO web. SAML dépend beaucoup de qui est l'utilisateur.
• Normes WS-Security / WS- *: elles se concentrent sur la communication entre les services SOAP. Ils sont spécifiques au format de messagerie au niveau de l'application (SOAP) et ils traitent des aspects de la messagerie, par exemple la fiabilité, la sécurité, la confidentialité, l'intégrité, l'atomicité, les événements ... Aucun ne couvre le contrôle d'accès et tous sont spécifiques à SOAP.

XACML est indépendant de la technologie. Il peut être appliqué aux applications java, aux services Web .NET, Python, Ruby ..., aux API REST, etc.

Voici des ressources intéressantes:

• le site web OASIS XACML
• la norme NIST ABAC

J'ai utilisé OAuth à quelques reprises et j'ai également utilisé d'autres méthodes (BASIC / DIGEST). Je suggère de tout cœur OAuth. Le lien suivant est le meilleur didacticiel que j'ai vu sur l'utilisation d'OAuth:

http://hueniverse.com/oauth/guide/

L'un des meilleurs messages que j'ai jamais rencontrés concernant la sécurité en ce qui concerne REST est terminé chez 1 RainDrop . Les API MySpace utilisent OAuth également pour la sécurité et vous avez un accès complet à leurs canaux personnalisés dans le code RestChess, avec lequel j'ai fait beaucoup d'exploration. C'était une démonstration chez Mix et vous pouvez trouver la publication ici .

Merci pour les excellents conseils. Nous avons fini par utiliser un en-tête HTTP personnalisé pour transmettre un jeton d'identité du client au service, en préparation de l'intégration de notre API RESTful avec le futur framework Zermatt Identity de Microsoft. J'ai décrit le problème ici et notre solution ici . J'ai également suivi les conseils de tweakt et acheté des services Web RESTful - un très bon livre si vous créez une API RESTful de quelque sorte que ce soit.

OWASP (Open Web Application Security Project) a quelques feuilles de triche couvrant tous les aspects du développement d'applications Web. Ce projet est une source d'information très précieuse et fiable. En ce qui concerne les services REST, vous pouvez vérifier cela: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

Je recommanderais OAuth 2/3. Vous pouvez trouver plus d'informations sur http://oauth.net/2/

J'ai beaucoup cherché sur la sécurité ws reposante et nous avons également fini par utiliser un jeton via un cookie du client au serveur pour authentifier les demandes. J'ai utilisé la sécurité Spring pour l'autorisation des demandes en service parce que je devais authentifier et autoriser chaque demande en fonction des politiques de sécurité spécifiées qui étaient déjà dans DB.

Le fait que le monde SOAP soit assez bien couvert par des normes de sécurité ne signifie pas qu'il est sécurisé par défaut. En premier lieu, les normes sont très complexes. La complexité n'est pas un très bon ami des vulnérabilités de sécurité et d'implémentation telles que les attaques par habillage de signature XML sont endémiques ici.

En ce qui concerne l'environnement .NET, je n'aiderai pas beaucoup, mais «Construire des services Web avec Java» (une brique avec ~ 10 auteurs) m'a beaucoup aidé à comprendre l'architecture de sécurité WS- * et, en particulier, ses bizarreries.

REST lui-même n'offre aucune norme de sécurité, mais des choses comme OAuth et SAML deviennent rapidement les normes dans cet espace. Cependant, l'authentification et l'autorisation ne sont qu'une petite partie de ce que vous devez considérer. De nombreuses vulnérabilités connues liées aux applications Web s'appliquent beaucoup aux API REST. Vous devez prendre en compte la validation des entrées, le craquage de session, les messages d'erreur inappropriés, les vulnérabilités internes des employés, etc. C'est un gros sujet.

Je veux ajouter (conformément à stinkeymatt), la solution la plus simple serait d'ajouter des certificats SSL à votre site. En d'autres termes, assurez-vous que votre URL est HTTPS: //. Cela couvrira votre sécurité de transport (coup pour le dollar). Avec les URL RESTful, l'idée est de rester simple (contrairement à WS * security / SAML), vous pouvez utiliser oAuth2 / openID connect ou même Basic Auth (dans les cas simples). Mais vous aurez toujours besoin de SSL / HTTPS. Veuillez vérifier la sécurité de l'API Web ASP.NET 2 ici: http://www.asp.net/web-api/overview/security (Articles et vidéos)

Comme @Nathan s'est retrouvé avec ce qui est un simple en-tête HTTP, et certains avaient dit OAuth2 et des certificats SSL côté client. L'essentiel est le suivant ... votre API REST ne devrait pas avoir à gérer la sécurité car cela devrait vraiment être en dehors de la portée de l'API.

Au lieu de cela, une couche de sécurité doit être placée dessus, qu'il s'agisse d'un en-tête HTTP derrière un proxy Web (une approche courante comme SiteMinder, Zermatt ou même Apache HTTPd), ou aussi compliqué que OAuth 2.

L'essentiel est que les demandes doivent fonctionner sans aucune interaction avec l'utilisateur final. Il suffit de s'assurer que la connexion à l'API REST est authentifiée. En Java EE, nous avons la notion d'un userPrincipalqui peut être obtenu sur unHttpServletRequest . Il est également géré dans le descripteur de déploiement qu'un modèle d'URL peut être sécurisé de sorte que le code API REST n'a plus besoin d'être vérifié.

Dans le monde WCF, j'utiliserais ServiceSecurityContext.Currentpour obtenir le contexte de sécurité actuel. Vous devez configurer votre application pour exiger une authentification.

Il y a une exception à la déclaration que j'ai eu ci-dessus et c'est l'utilisation d'un nonce pour empêcher les rediffusions (qui peuvent être des attaques ou quelqu'un qui soumet simplement les mêmes données deux fois). Cette partie ne peut être gérée que dans la couche application.

Pour la sécurité des applications Web, vous devriez jeter un oeil à OWASP ( https://www.owasp.org/index.php/Main_Page ) qui fournit des fiches techniques pour diverses attaques de sécurité. Vous pouvez intégrer autant de mesures que possible pour sécuriser votre application. En ce qui concerne la sécurité des API (autorisation, authentification, gestion des identités), il existe plusieurs façons comme déjà mentionné (Basic, Digest et OAuth). Il y a des trous de boucle dans OAuth1.0, vous pouvez donc utiliser OAuth1.0a (OAuth2.0 n'est pas largement adopté en raison de problèmes avec la spécification)

Cela fait un moment mais la question est toujours d'actualité, même si la réponse a peut-être un peu changé.

Une passerelle API serait une solution flexible et hautement configurable. J'ai testé et utilisé un peu de KONG et j'ai vraiment aimé ce que j'ai vu. KONG fournit sa propre API REST d'administration que vous pouvez utiliser pour gérer les utilisateurs.

Express-gateway.io est plus récent et est également une passerelle API.