Recommandations pour atténuer les 10 principales menaces de la sécurité des API OWASP à l’aide d’API Management

  • Article

S’APPLIQUE À : tous les niveaux de Gestion des API

La communauté OWASP (Open Web Application Security Project) travaille pour améliorer la sécurité logicielle par le biais de ses projets logiciels open source communautaires, des centaines de chapitres dans le monde entier, des dizaines de milliers de membres et en hébergeant des conférences locales et internationales.

Le Projet de sécurité des API OWASP se concentre sur les stratégies et solutions pour comprendre et atténuer les vulnérabilités uniques et les risques de sécurité des API. Dans cet article, nous allons discuter des recommandations d’utilisation d’Azure API Management pour atténuer les 10 principales menaces d’API identifiées par OWASP.

Remarque

En plus de suivre les recommandations de cet article, vous pouvez activer Defender pour les API, une fonctionnalité de Microsoft Defender pour le cloud, permettant d’obtenir des insights sur la sécurité des API, des recommandations et de détecter les menaces. En savoir plus sur l’utilisation de Defender pour les API avec Gestion des API

Autorisation au niveau de l’objet rompue

Les objets API qui ne sont pas protégés avec le niveau d’autorisation approprié peuvent être vulnérables aux fuites de données et à la manipulation de données non autorisées par le biais d’identificateurs d’accès aux objets faibles. Par exemple, un attaquant peut exploiter un identificateur d’objet entier, qui peut être itéré.

Pour plus d’informations sur cette menace : API1:2019 Broken Object Level Authorization (Autorisation au niveau de l’objet rompue)

Recommandations

  • Le meilleur endroit pour implémenter l’autorisation au niveau de l’objet se trouve dans l’API back-end elle-même. Au niveau du back-end, les décisions d’autorisation correctes peuvent être prises au niveau de la requête (ou de l’objet), le cas échéant, en utilisant la logique applicable au domaine et à l’API. Envisagez des scénarios où une requête donnée peut produire des niveaux de détail différents dans la réponse, en fonction des autorisations du demandeur et de l’autorisation.

  • Si une API vulnérable actuelle ne peut pas être modifiée au niveau du serveur principal, API Management peut être utilisé comme solution de secours. Par exemple :

    • Utilisez une stratégie personnalisée pour implémenter une autorisation au niveau de l’objet, si elle n’est pas implémentée dans le back-end.

    • Implémentez une stratégie personnalisée pour mapper les identificateurs de la requête au serveur principal et à partir du back-end au client, afin que les identificateurs internes ne soient pas exposés.

      Dans ces cas, la stratégie personnalisée peut être une expression de stratégie avec une recherche (par exemple, un dictionnaire) ou une intégration à un autre service via la stratégie de demande d’envoi.

  • Pour les scénarios GraphQL, appliquez l’autorisation au niveau de l’objet via la stratégie de validation de requête GraphQL, à l’aide de l’élément authorize.

Authentification utilisateur rompue

Les mécanismes d’authentification sont souvent implémentés incorrectement ou manquants, ce qui permet aux attaquants d’exploiter les failles d’implémentation pour accéder aux données.

Pour plus d’informations sur cette menace : API2:2019 Broken User Authentication (Authentification utilisateur rompue)

Recommandations

Utilisez API Management pour l’authentification et l’autorisation de l’utilisateur :

  • Authentification : API Management prend en charge les méthodes d’authentification suivantes :

    • Stratégie d’authentification de base : informations d’identification du nom d’utilisateur et du mot de passe.

    • Clé d’abonnement : une clé d’abonnement fournit un niveau de sécurité similaire à celui de l’authentification de base et peut ne pas être suffisante seule. Si la clé d’abonnement est compromise, un attaquant peut obtenir un accès illimité au système.

    • Stratégie de certificat client : l’utilisation de certificats clients est plus sécurisée que les informations d’identification de base ou la clé d’abonnement, mais elle n’autorise pas la flexibilité fournie par les protocoles d’autorisation basés sur des jetons tels que OAuth 2.0.

  • Autorisation : API Management prend en charge une stratégie de validation de JWT pour vérifier la validité d’un jeton d’accès OAuth 2.0 JWT entrant en fonction des informations obtenues à partir du point de terminaison de métadonnées du fournisseur d’identité OAuth. Configurez la stratégie pour vérifier les revendications de jeton, l’audience et l’heure d’expiration pertinentes. En savoir plus sur la protection d’une API à l’aide de l’autorisation OAuth 2.0 et Microsoft Entra ID.

Recommandations supplémentaires :

  • Utilisez des stratégies dans Gestion des API pour augmenter la sécurité. Par exemple, la limitation du taux d’appel ralentit les mauvais acteurs à l’aide d’attaques par force brute pour compromettre les informations d’identification.

  • Les API doivent utiliser TLS/SSL (sécurité de transport) pour protéger les informations d’identification ou les jetons. Les informations d’identification et les jetons doivent être envoyés dans les en-têtes de requête et non en tant que paramètres de requête.

  • Dans le portail des développeurs API Management, configurez Microsoft Entra ID ou Azure Active Directory B2C comme fournisseur d’identité pour augmenter la sécurité du compte. Le portail des développeurs utilise CAPTCHA pour atténuer les attaques par force brute.

Exposition excessive des données

Une bonne conception d’interface API est étonnamment difficile. Souvent, en particulier avec les API héritées qui ont évolué au fil du temps, les interfaces de requête et de réponse contiennent plus de champs de données que les applications consommatrices n’en ont besoin.

Un mauvais acteur peut tenter d’accéder directement à l’API (peut-être en relisant une demande valide) ou reniflant le trafic entre le serveur et l’API. L’analyse des actions d’API et les données disponibles peuvent produire des données sensibles pour l’attaquant, qui ne sont pas exposées ni utilisée par l’application frontale.

Pour plus d’informations sur cette menace : API3:2019 Excessive Data Exposure (Exposition excessive des données)

Recommandations

  • La meilleure approche pour atténuer cette vulnérabilité consiste à s’assurer que les interfaces externes définies sur l’API back-end sont conçues avec soin et, dans l’idéal, indépendamment de la persistance des données. Ils doivent contenir uniquement les champs requis par les consommateurs de l’API. Les API doivent être examinées fréquemment et les champs hérités déconseillés, puis supprimés.

    Dans API Management, utilisez :

    • Révisions pour contrôler avec grâce les changements non cassants, par exemple, l’ajout d’un champ à une interface. Vous pouvez utiliser des révisions avec une implémentation de contrôle de version sur le serveur principal.

    • Versions pour les changements cassants, par exemple, la suppression d’un champ d’une interface.

  • S’il n’est pas possible de modifier la conception de l’interface principale et si les données excessives sont une préoccupation, utilisez les stratégies de transformation API Management pour réécrire les charges utiles de réponse et masquer ou filtrer les données. Par exemple, supprimez les propriétés JSON inutiles d’un corps de réponse.

  • La validation du contenu de réponse dans API Management peut être utilisée avec un schéma XML ou JSON pour bloquer les réponses avec des propriétés non documentées ou des valeurs incorrectes. La stratégie prend également en charge le blocage des réponses dépassant une taille spécifiée.

  • Utilisez la stratégie de validation de code d’état pour bloquer les réponses avec des erreurs non définies dans le schéma de l’API.

  • Utilisez la stratégie de validation des en-têtes pour bloquer les réponses avec des en-têtes qui ne sont pas définis dans le schéma ou qui ne se conforment pas à leur définition dans le schéma. Supprimez les en-têtes indésirables avec la stratégie de définition d’en-tête.

  • Pour les scénarios GraphQL, utilisez la stratégie de validation de requête GraphQL pour valider les requêtes GraphQL, autoriser l’accès à des chemins d’accès de requête spécifiques et limiter la taille de réponse.

Absence de ressources et limitation du débit

L’absence de limitation de débit peut entraîner une exfiltration des données ou des attaques DDoS réussies sur les services principaux, ce qui entraîne une panne pour tous les consommateurs.

Pour plus d’informations sur cette menace : API4:2019 Lack of resources and rate limiting (Manque de ressources et limitation du débit)

Recommandations

  • Utilisez les stratégies de limite de débit (à court terme) et de limite de quota (à long terme) pour contrôler le nombre autorisé d’appels d’API ou de bande passante par consommateur.

  • Définissez des définitions d’objet de requête strictes et leurs propriétés dans la définition OpenAPI. Par exemple, définissez la valeur maximale pour les entiers de pagination, maxLength et l’expression régulière (regex) pour les chaînes. Appliquez ces schémas avec les stratégies de validation de contenu et de validation des paramètres dans API Management.

  • Appliquez la taille maximale de la requête avec la stratégie de validation de contenu.

  • Optimisez les performances avec la mise en cache intégrée, réduisant ainsi la consommation de ressources processeur, mémoire et réseau pour certaines opérations.

  • Appliquez l’authentification pour les appels d’API (voir Authentification utilisateur rompue). Révoquez l’accès pour les utilisateurs abusifs. Par exemple, désactivez la clé d’abonnement, bloquez l’adresse IP avec la stratégie de limitation des adresses IP de l’appelant ou rejetez les requêtes d’une revendication d’utilisateur donnée à partir d’un jeton JWT.

  • Appliquez une stratégie CORS pour contrôler les sites web autorisés à charger les ressources servies via l’API. Pour éviter les configurations trop permissives, n’utilisez pas de valeurs génériques (*) dans la stratégie CORS.

  • Réduisez le temps nécessaire à un service back-end pour répondre. Plus le service back-end prend de temps pour répondre, plus la connexion est occupée dans API Management, ce qui réduit le nombre de requêtes pouvant être traitées dans un délai donné.

  • Bien que API Management puisse protéger les services principaux contre les attaques DDoS, il peut être vulnérable à ces attaques proprement dites. Déployez un service de protection bot devant Gestion des API (par exemple, Azure Application Gateway, Azure Front Door ou Azure DDoS Protection) pour mieux vous protéger contre les attaques DDoS. Lorsque vous utilisez un WAF avec Azure Application Gateway ou Azure Front Door, envisagez d’utiliser Microsoft_BotManagerRuleSet_1.0.

Autorisation au niveau de la fonction rompue

Les stratégies de contrôle d’accès complexes avec des hiérarchies, groupes et rôles différents, et une séparation peu claire entre les fonctions administratives et régulières entraîne des failles d’autorisation. En exploitant ces problèmes, les attaquants accèdent aux ressources ou aux fonctions administratives d’autres utilisateurs.

Pour plus d’informations sur cette menace : API5:2019 Broken function level authorizationn (Autorisation au niveau de la fonction rompue)

Recommandations

  • Par défaut, protégez tous les points de terminaison d’API dans API Management avec des clés d’abonnement.

  • Définissez une stratégie de validation de JWT et appliquez les revendications de jeton requises. Si certaines opérations nécessitent une application des revendications plus stricte, définissez des stratégies validate-jwt supplémentaires pour ces opérations uniquement.

  • Utilisez un réseau virtuel Azure ou Private Link pour masquer les points de terminaison d’API à partir d’Internet. En savoir plus sur les options de réseau virtuel avec API Management.

  • Ne définissez pas d’opérations d’API génériques (autrement dit, les API qui interceptent tout avec * comme chemin d’accès). Assurez-vous qu’API Management sert uniquement les requêtes pour les points de terminaison définis explicitement et que les requêtes aux points de terminaison non définis sont rejetées.

  • Ne publiez pas d’API avec des produits ouverts qui ne nécessitent pas d’abonnement.

Affectation en masse

Si une API offre plus de champs que le client pour une action donnée, un attaquant peut injecter des propriétés excessives pour effectuer des opérations non autorisées sur les données. Les attaquants peuvent découvrir des propriétés non documentées en inspectant le format des requêtes et des réponses ou d’autres API, ou en les devinant. Cette vulnérabilité est particulièrement applicable si vous n’utilisez pas de langages de programmation fortement typés.

Pour plus d’informations sur cette menace : API6:2019 Mass assignment (Affectation en masse)

Recommandations

  • Les interfaces d’API externes doivent être découplées de l’implémentation des données internes. Évitez de lier des contrats d’API directement aux contrats de données dans les services principaux. Passez fréquemment en revue la conception de l’API, abandonnez et supprimez les propriétés héritées à l’aide du contrôle de version dans API Management.

  • Définissez précisément des contrats XML et JSON dans le schéma de l’API et utilisez des stratégies de validation de contenu et de validation des paramètres pour bloquer les requêtes et les réponses avec des propriétés non documentées. Le blocage des requêtes avec des propriétés non documentées atténue les attaques, tandis que le blocage des réponses avec des propriétés non documentées rend plus difficile l’ingénierie inverse des vecteurs d’attaque potentiels.

  • Si l’interface back-end ne peut pas être modifiée, utilisez des stratégies de transformation pour réécrire des charges utiles de requête et de réponse et dissocier les contrats d’API des contrats principaux. Par exemple, masquez ou filtrez des données, ou supprimez les propriétés JSON inutiles.

Configuration incorrecte de la sécurité

Les attaquants peuvent tenter d’exploiter des vulnérabilités de configuration incorrecte de la sécurité, telles que :

  • Renforcement de la sécurité manquant
  • Fonctionnalités inutiles activées
  • Connexions réseau à Internet inutilement ouvertes
  • Utilisation de protocoles ou de chiffrements faibles
  • Autres paramètres ou points de terminaison qui peuvent autoriser l’accès non autorisé au système

Pour plus d’informations sur cette menace : API7:2019 Security misconfiguration (Configuration incorrecte de la sécurité)

Recommandations

  • Configurez correctement le protocole TLS de passerelle. N’utilisez pas de protocoles (par exemple, TLS 1.0, 1.1) ni de chiffrements vulnérables.

  • Configurez les API pour accepter le trafic chiffré uniquement, par exemple via des protocoles HTTPS ou WSS.

  • Envisagez de déployer API Management derrière un point de terminaison privé ou attaché à un réseau virtuel déployé en mode interne. Dans les réseaux internes, l’accès peut être contrôlé à partir du réseau privé (via un pare-feu ou des groupes de sécurité réseau) et à partir d’Internet (via un proxy inverse).

  • Utilisez des stratégies Azure API Management :

    • Héritez toujours des stratégies parentes par le biais de la balise <base>.

    • Lorsque vous utilisez OAuth 2.0, configurez et testez la stratégie de validation de JWT pour vérifier l’existence et la validité du jeton JWT avant d’atteindre le serveur principal. Vérifiez automatiquement l’heure d’expiration du jeton, la signature de jeton et l’émetteur. Appliquez les revendications, les audiences, l’expiration du jeton et la signature de jeton par le biais des paramètres de stratégie.

    • Configurez la stratégie CORS et n’utilisez le caractère générique * pour aucune option de configuration. Au lieu de cela, répertoriez explicitement les valeurs autorisées.

    • Définissez des stratégies de validation sur prevent dans les environnements de production pour valider les schémas JSON et XML, les en-têtes, les paramètres de requête et les codes d’état, et pour appliquer la taille maximale pour la requête ou la réponse.

    • Si API Management se trouve en dehors d’une limite réseau, la validation d’adresse IP du client est toujours possible à l’aide de la stratégie de limitation des adresses IP de l’appelant. Assurez-vous qu’il utilise une liste verte, et non une liste rouge.

    • Si des certificats clients sont utilisés entre l’appelant et API Management, utilisez la stratégie de validation de certificat client. Vérifiez que les attributs validate-revocation, validate-trust, validate-not-before et validate-not-after sont tous définis sur true.

      • Les certificats clients (TLS mutuel) peuvent également être appliqués entre API Management et le serveur principal. Le serveur principal doit :

        • Avoir des informations d’identification d’autorisation configurées

        • Valider la chaîne de certificats, le cas échéant

        • Valider le nom du certificat, le cas échéant

  • Pour les scénarios GraphQL, utilisez la stratégie de validation de requête GraphQL. Vérifiez que l’élément authorization et les attributs max-size et max-depth sont définis.

  • Ne stockez pas les secrets dans les fichiers de stratégie ou dans le contrôle de code source. Utilisez toujours des valeurs nommées API Management ou récupérez les secrets au moment de l’exécution à l’aide d’expressions de stratégie personnalisées.

    • Les valeurs nommées doivent être intégrées à Key Vault ou chiffrées dans API Management en étant marquées comme « secrètes ». Ne stockez jamais de secrets dans des valeurs nommées en texte brut.

  • Publiez des API via des produits qui nécessitent des abonnements. N’utilisez pas de produits ouverts qui ne nécessitent pas d’abonnement.

  • Utilisez l’intégration Key Vault pour gérer tous les certificats : cela centralise la gestion des certificats et peut faciliter les tâches de gestion des opérations telles que le renouvellement ou la révocation de certificats.

  • Lorsque vous utilisez la passerelle auto-hébergée, assurez-vous qu’il existe un processus en place pour mettre à jour l’image régulièrement vers la dernière version.

  • Représente les services principaux en tant qu’entités principales. Configurez les informations d’identification d’autorisation, la validation de la chaîne de certificats et la validation de nom de certificat le cas échéant.

  • En cas d’utilisation du portail des développeurs :

    • Si vous choisissez d’héberger automatiquement le portail des développeurs, assurez-vous qu’il existe un processus en place pour mettre régulièrement à jour le portail auto-hébergé vers la dernière version. Les mises à jour de la version gérée par défaut sont automatiques.

    • Utilisez Microsoft Entra ID ou Azure Active Directory B2C pour l’inscription et la connexion des utilisateurs. Désactivez l’authentification par défaut du nom d’utilisateur et du mot de passe, ce qui est moins sécurisé.

    • Affectez des groupes d’utilisateurs aux produits pour contrôler la visibilité des API dans le portail.

  • Utilisez Azure Policy pour appliquer des autorisations de configuration au niveau des ressources et de contrôle d’accès en fonction du rôle (RBAC) API Management pour contrôler l’accès aux ressources. Accordez les privilèges minimaux requis à chaque utilisateur.

  • Utilisez une approche de processus DevOps et d’infrastructure en tant que code en dehors d’un environnement de développement pour garantir la cohérence des modifications de configuration et de contenu API Management et réduire les erreurs humaines.

  • N’utilisez aucune fonctionnalité déconseillée.

Injection

Tout point de terminaison acceptant des données utilisateur est potentiellement vulnérable à une attaque par injection. Voici quelques exemples, non exhaustifs :

  • Injection de commandes, où un mauvais acteur tente de modifier la requête d’API pour exécuter des commandes sur le système d’exploitation hébergeant l’API

  • Injection SQL, où un mauvais acteur tente de modifier la requête d’API pour exécuter des commandes et des requêtes sur la base de données dont une API dépend

Pour plus d’informations sur cette menace : API8:2019 Injection (Injection)

Recommandations

  • Les stratégies de Web Application Firewall (WAF) modernes couvrent de nombreuses vulnérabilités d’injection courantes. Bien qu’API Management n’ait pas de composant WAF intégré, le déploiement d’un WAF en amont (devant) de l’instance API Management est fortement recommandé. Par exemple, utilisez Azure Application Gateway ou Azure Front Door.

    Important

    Assurez-vous qu’un acteur incorrect ne peut pas contourner la passerelle hébergeant le WAF et vous connecter directement à la passerelle API Management ou à l’API back-end elle-même. Les atténuations possibles sont les suivantes : listes de contrôle d’accès réseau, utilisation d’une stratégie API Management pour restreindre le trafic entrant par adresse IP cliente, suppression de l’accès public où il n’est pas nécessaire et authentification par certificat client (également appelée TLS ou mTLS mutuel).

  • Utilisez des stratégies de validation de schéma et de paramètre, le cas échéant, pour limiter et valider davantage la requête avant qu’elle n’atteigne le service d’API back-end.

    Le schéma fourni avec la définition d’API doit avoir une contrainte de modèle regex appliquée aux champs vulnérables. Chaque expression régulière doit être testée pour s’assurer qu’elle limite suffisamment le champ pour atténuer les tentatives d’injection courantes.

Gestion incorrecte des ressources

Les vulnérabilités liées à la gestion incorrecte des ressources sont les suivantes :

  • Absence de documentation sur l’API ou d’informations de propriété appropriées

  • Nombre excessif de versions d’API plus anciennes, qui peuvent manquer de correctifs de sécurité

Pour plus d’informations sur cette menace : API9:2019 Improper assets management (Gestion incorrecte des ressources)

Recommandations

  • Utilisez une spécification OpenAPI bien définie comme source pour l’importation d’API REST. La spécification permet l’encapsulation de la définition d’API, y compris les métadonnées correctement documentées.

    • Utilisez des interfaces API avec des chemins précis, des schémas de données, des en-têtes, des paramètres de requête et des codes d’état. Évitez les opérations génériques. Fournissez des descriptions pour chaque API et opération, et incluez les informations de contact et de licence.

    • Évitez les points de terminaison qui ne contribuent pas directement à l’objectif métier. Ils augmentent inutilement la zone de surface d’attaque et compliquent l’évolution de l’API.

  • Utilisez des révisions et des versions dans API Management pour régir et contrôler les points de terminaison de l’API. Disposer d’une stratégie de contrôle de version principale forte et valider un nombre maximal de versions d’API prises en charge (par exemple, 2 ou 3 versions antérieures). Envisagez de déprécier et de supprimer rapidement les versions plus anciennes, souvent moins sécurisées, d’API.

  • Utilisez une instance API Management par environnement (comme le développement, le test et la production). Vérifiez que chaque instance API Management se connecte à ses dépendances dans le même environnement. Par exemple, dans l’environnement de test, la ressource de test API Management doit se connecter à une ressource de test Azure Key Vault et aux versions de test des services principaux. Utilisez des pratiques d’automatisation et d’infrastructure en tant que code DevOps pour vous aider à maintenir la cohérence et la précision entre les environnements et à réduire les erreurs humaines.

  • Utilisez des balises pour organiser les API et les produits, et les regrouper pour la publication.

  • Publier des API à des fins de consommation via le portail des développeurs intégré. Vérifiez que la documentation de l’API est à jour.

  • Découvrez les API non documentées ou non managées, et exposez-les via API Management pour un meilleur contrôle.

Journalisation et surveillance insuffisantes

La journalisation et la surveillance insuffisantes, associées à l’intégration manquante ou inefficace à la réponse aux incidents, permettent aux attaquants de poursuivre les systèmes d’attaque, de maintenir la persistance, de pivoter vers d’autres systèmes de falsification, et d’extraire ou de détruire des données. La plupart des études sur les violations montrent que le temps de détection d’une violation est supérieur à 200 jours, généralement détecté par des parties externes plutôt que par des processus internes ou une surveillance.

Pour plus d’informations sur cette menace : API10:2019 Insufficient logging and monitoring (Journalisation et surveillance insuffisantes)

Recommandations

Étapes suivantes

Pour en savoir plus :