Question 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 bonnes pratiques pour gérer la sécurité (Authentification, Autorisation, Gestion des identités)?

Lors de la construction d'une API SOAP, vous avez WS-Security comme guide et beaucoup de documentation existe sur le sujet. J'ai trouvé moins d'informations sur la sécurisation des points de terminaison REST.

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

Toute discussion ou lien vers des documents pertinents serait très apprécié. Si cela est important, nous utiliserons WCF avec des messages sérialisés POX / JSON pour nos API / services REST construits en utilisant la version 3.5 du .NET Framework.


747
2017-08-11 05:44


origine


Réponses:


Comme dit tweakt, Amazon S3 est un bon modèle pour travailler. Leurs signatures de requête ont certaines fonctionnalités (telles que l'incorporation d'un horodatage) qui aident à se prémunir contre la réexécution de requêtes accidentelle et malveillante.

La bonne chose à propos de HTTP Basic est que pratiquement toutes les bibliothèques HTTP le supportent. Vous devrez, bien sûr, exiger SSL dans ce cas, car l'envoi de mots de passe en clair sur le réseau est presque toujours une mauvaise chose. Basic 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 requiert un roundtrip supplémentaire pour échanger la valeur nonce. Avec Basic, les appelants envoie simplement les informations d'identification la première fois.

Une fois l'identité du client établie, l'autorisation n'est vraiment qu'un problème d'implémentation. Toutefois, 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 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.


280
2017-08-11 08:45



Il n'existe aucune norme pour REST autre que HTTP. Il existe des services REST établis là-bas. Je vous suggère de jeter un coup d'œil sur eux et de comprendre leur fonctionnement.

Par exemple, nous avons emprunté beaucoup d'idées au service S3 REST d'Amazon en développant le 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 HTTP Basic auth over SSL. Vous devez décider ce qui fonctionne le mieux dans votre situation.

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


108
2017-08-11 06:07



Vous pouvez également jeter un oeil à OAuth, un protocole ouvert émergent 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 le lait apis "repos" (pas forcément de bons exemples d'apis reposants, mais de bons exemples de l'approche par jeton).


68
2017-09-18 02:55



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é d'utilisateurs identifiés par des certificats. Mais un certain nombre de gouvernements / entreprises les transmettent à leurs utilisateurs. L'utilisateur n'a pas à s'inquiéter 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 requise. (Ne pas impliquer que toutes / toutes les autres solutions mentionnées nécessitent des sessions)


40
2017-09-25 19:39



Tout le monde dans ces réponses a négligé le vrai contrôle d'accès / autorisation.

Si, par exemple, vos API / services Web REST concernent l'enregistrement POST / GET d'enregistrements médicaux, vous pouvez définir des règles de contrôle d'accès pour savoir 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 soin
  • personne ne peut poster des données médicales en dehors des heures de pratique (par exemple 9 à 5)
  • les utilisateurs finaux peuvent obtenir des dossiers médicaux qu'ils possèdent ou des dossiers médicaux des patients dont ils sont le gardien
  • 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 détaillées, 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 sont pour:

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

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

Voici des ressources intéressantes:


34
2017-09-24 22:22



J'ai utilisé OAuth plusieurs fois, et j'ai aussi utilisé d'autres méthodes (BASIC / DIGEST). Je suggère sans réserve OAuth. Le lien suivant est le meilleur tutoriel que j'ai vu sur l'utilisation d'OAuth:

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


25
2018-01-09 21:25



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, le stockage de mot de passe. Utilisez les normes.

  • Utilisation Max Retry et fonctions de prison dans Login.

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

JWT (jeton Web JSON)

  • Utilisez une clé aléatoire compliquée (JWT Secret) pour forcer brutalement le jeton très fort.

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

  • Faire l'expiration du jeton (TTL, RTTL) aussi court que possible.

  • Ne stockez pas de données sensibles dans le JWT charge utile, il peut être décodé facilement.

OAuth

  • Toujours valider redirect_uri côté serveur pour autoriser uniquement les URL en liste blanche.

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

  • Utiliser le paramètre d'état avec un hachage aléatoire pour éviter CSRF sur le OAuth processus d'authentification.

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

Accès

  • Limiter les requêtes (Throttling) pour éviter les attaques DDoS / force brute.

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

  • Utilisation HSTS en-tête avec SSL pour éviter l'attaque par bande SSL.

Contribution 

  • Utilisez la méthode HTTP appropriée en fonction de l'opération: GET (lis), POST (créer), PUT/PATCH (remplacer / mettre à jour), et DELETE (pour supprimer un enregistrement), et répondre avec 405 Method Not Allowed si la méthode demandée n'est pas appropriée pour la ressource demandée.

  • Valider le type de contenu sur demande Accept en-tête (Négociation de contenu) pour autoriser uniquement votre format pris en charge (par ex. application/xml, application/json, etc.) et répondez avec 406 Not Acceptable réponse si elle ne correspond pas.

  • Valider content-type des données publiées que vous acceptez (par ex. application/x-www-form-urlencoded, multipart/form-data, application/json, etc).

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

  • N'utilisez aucune donnée sensible (informations d'identification, mots de passe, jetons de sécurité ou clés API) dans l'URL, mais utilisez la norme Authorization entête.

  • Utilisez un service API Gateway pour activer la mise en cache, Rate Limit les stratégies (par exemple Quota, Spike Arrest, Limite de fréquence simultanée) et déployez les ressources API dynamiquement.

En traitement

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

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

  • Ne pas auto-incrémenter les ID. Utilisez UUID à la place.

  • 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'extension d'entité n'est pas activée pour éviter la bombe Billion Laughs / XML via une attaque d'expansion d'entité exponentielle.

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

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

  • Ne pas oublier de tourner le DÉBOGUER mode OFF.

Sortie

  • Envoyer X-Content-Type-Options: nosniff entête.

  • Envoyer X-Frame-Options: deny entête.

  • Envoyer Content-Security-Policy: default-src 'none' entête.

  • Supprimer les en-têtes d'empreintes digitales - X-Powered-By, Server, X-AspNet-Version etc.

  • Obliger content-type pour votre réponse, si vous retournez application/json alors votre type de contenu de réponse est application/json.

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

  • Renvoie 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).


22
2017-11-08 20:29