Comment APISIX protège contre les 10 principales menaces de sécurité des API selon OWASP

Avec l'utilisation croissante et la dépendance aux API dans le paysage numérique interconnecté d'aujourd'hui, les menaces de sécurité les ciblant ont également augmenté au fil des années. En 2023, l'Open Web Application Security Project (OWASP) a identifié les nouvelles Top 10 menaces à la sécurité des API. Dans cet article de blog, nous explorerons chaque menace et verrons comment APISIX peut les contrer avec des exemples.

L'OWASP est une communauté mondialement reconnue qui publie régulièrement des recherches liées à la cybersécurité.

Voici la liste des risques de sécurité mentionnés par l'OWASP :

1. Autorisation au niveau des objets défaillante
2. Authentification défaillante
3. Autorisation au niveau des propriétés des objets défaillante
4. Consommation de ressources non restreinte
5. Autorisation au niveau des fonctions défaillante
6. Accès non restreint aux flux métiers sensibles
7. Falsification de requête côté serveur (SSRF)
8. Mauvaise configuration de la sécurité
9. Gestion inadéquate des inventaires
10. Consommation non sécurisée des API

1. Autorisation au niveau des objets défaillante

Menace : Les API exposent souvent des points de terminaison qui gèrent des identifiants d'objets, ce qui peut entraîner des problèmes de contrôle d'accès au niveau des objets. Les attaquants peuvent exploiter ces vulnérabilités pour accéder de manière non autorisée aux données.

Exemple : Une institution de santé propose un portail en ligne pour les patients. En raison d'une faille dans la conception du portail, une fois qu'un patient est authentifié, il peut modifier l'URL ou les paramètres de la requête pour accéder aux dossiers médicaux associés à un autre ID de patient. Par exemple, un patient nommé Steve se connecte au portail pour consulter ses dossiers médicaux. Ses dossiers sont accessibles via l'URL https://healthportal.com/patient/123. Par curiosité, Steve modifie l'URL en https://healthportal.com/patient/124 et découvre qu'il peut maintenant consulter les dossiers médicaux d'un autre patient. Cela expose une violation significative de la confidentialité et enfreint des réglementations comme la Health Insurance Portability and Accountability Act (HIPAA).

Recommandation : Mettez en place un mécanisme d'autorisation approprié qui s'appuie sur les politiques et la hiérarchie des utilisateurs. La passerelle APISIX prend en charge les flux d'autorisation basés sur OAuth2 ou JWT grâce à des plugins. Vous pouvez utiliser la politique OAuth2 pour vérifier le jeton à chaque requête.

Utilisez un contrôle d'accès granulaire via le système de contrôle d'accès basé sur les rôles (RBAC) d'APISIX en l'intégrant à Open Policy Agent (OPA). En configurant des rôles et permissions spécifiques dans APISIX et en associant ces rôles à des utilisateurs ou jetons spécifiques, vous pouvez vous assurer que les requêtes vers des points de terminaison sensibles sont correctement autorisées.

2. Authentification défaillante

Menace : Des mécanismes d'authentification mal implémentés peuvent permettre aux attaquants de compromettre les jetons d'authentification ou simplement de forcer les points de terminaison de connexion par force brute en l'absence de limitation de taux.

Exemple : Le système bancaire a mis en place un mécanisme d'authentification personnalisé. Cependant, en raison d'un manque de revue de sécurité et de tests appropriés, il y avait une vulnérabilité dans le flux d'authentification. Plus précisément, après qu'un utilisateur ait entré son nom d'utilisateur et son mot de passe, le système générait un jeton de session prévisible, comme une combinaison du nom d'utilisateur et d'un horodatage. Un attaquant, conscient de ce défaut, pourrait facilement prédire le jeton de session d'un autre utilisateur.

Recommandation : Tout d'abord, comprenez tous les flux d'authentification possibles vers l'API, et ne réinventez pas la roue en matière d'authentification ! APISIX prend en charge le flux d'autorisation standard OpenID Connect (OIDC). Au lieu de jetons de session prévisibles, APISIX peut s'intégrer à des fournisseurs d'identité externes comme Keycloak ou à des systèmes de gestion de session en utilisant des plugins pour s'assurer que les jetons de session sont aléatoires, chiffrés et ont une durée de vie limitée.

Pour prévenir les attaques par force brute sur les comptes utilisateurs, le plugin de limitation de taux d'APISIX peut être utilisé. Cela garantit que si plusieurs tentatives de connexion échouent en peu de temps, l'IP ou l'utilisateur est temporairement bloqué. Pour garantir la confidentialité et l'intégrité des données, APISIX prend en charge le chiffrement SSL/TLS. Cela garantit que les informations d'identification des utilisateurs et d'autres données sensibles sont chiffrées pendant la transmission.

3. Autorisation au niveau des propriétés des objets défaillante

Menace : Cette menace survient en raison de l'absence ou d'une validation d'autorisation inadéquate au niveau des propriétés des objets, entraînant une exposition ou une manipulation non autorisée des informations.

Exemple : L'API d'une plateforme de shopping en ligne permet aux utilisateurs enregistrés de mettre à jour les détails de leur profil, tels que leur nom, leur adresse e-mail, leur adresse de livraison et leurs informations de paiement. De plus, chaque profil utilisateur a une propriété appelée userType, qui peut être soit regular soit admin. En raison d'un problème dans la conception de l'API, les utilisateurs peuvent également modifier la propriété userType dans leurs requêtes de mise à jour de profil. Supposons qu'Alice, une utilisatrice régulière, découvre cette faille lorsqu'elle inspecte les requêtes API à l'aide des outils de développement de son navigateur. Elle remarque que lors de la mise à jour de son profil, une charge utile JSON est envoyée au serveur. Alice modifie la valeur de userType en admin et envoie la requête. À sa grande surprise, son profil est mis à jour, et elle a maintenant des privilèges administratifs sur la plateforme, lui permettant d'accéder à des données sensibles, de modifier les listes de produits et même de consulter l'historique des commandes d'autres utilisateurs.

Recommandation : Assurez-vous que les propriétés des objets exposées sont accessibles à l'utilisateur et gardez les structures de données renvoyées minimales, en fonction des besoins métiers. Pour y parvenir, vous pouvez utiliser le plugin de validation de requête d'APISIX qui peut valider les requêtes entrantes par rapport à un schéma prédéfini. Ou utilisez le système RBAC d'APISIX pour configurer des rôles pour les utilisateurs réguliers et les administrateurs. Pour supprimer les données inutiles exposées au client, APISIX fournit un plugin de réécriture de réponse qui peut modifier la réponse de l'API à la volée.

4. Consommation de ressources non restreinte

Menace : Les attaquants peuvent exploiter les API pour consommer des ressources excessives, entraînant des attaques par déni de service ou une augmentation des coûts opérationnels.

Exemple : Un service de stockage de fichiers basé sur le cloud permet aux utilisateurs de télécharger et de stocker des fichiers, de les partager avec d'autres et d'y accéder depuis n'importe où. Le service n'a aucune restriction sur le nombre de fichiers qu'un utilisateur peut télécharger simultanément ou sur la taille de chaque fichier. En conséquence, un utilisateur malveillant ou un bot peut télécharger un nombre énorme de fichiers extrêmement volumineux en succession rapide, consommant une quantité importante de ressources serveur. Cela peut entraîner des temps de réponse plus lents pour les autres utilisateurs, des plantages potentiels du serveur et une augmentation des coûts d'infrastructure pour le fournisseur de services.

Recommandation :

• Définissez et appliquez des tailles maximales de données pour tous les paramètres et charges utiles entrants. Utilisez le plugin de contrôle client pour définir la taille maximale du corps de la requête afin que les utilisateurs ne puissent pas télécharger des fichiers excessivement volumineux. Ou utilisez le plugin de validation de requête pour valider les chaînes de requête, en particulier celles contrôlant le nombre d'enregistrements renvoyés. Pour bloquer un bot, un script ou un agent utilisateur envoyant des données indésirables, vous pouvez utiliser le plugin de restriction d'agent utilisateur.
• Mettez en place une limitation de taux en fonction des besoins métiers. APISIX fournit les plugins limit-req, limit-conn et limit-count qui peuvent restreindre le taux auquel un utilisateur ou une adresse IP peut faire des requêtes. Cela garantit que les utilisateurs ne peuvent pas inonder le système avec un grand nombre de requêtes rapides.

5. Autorisation au niveau des fonctions défaillante

Menace : Les politiques de contrôle d'accès sont parfois trop complexes, avec divers niveaux, groupes et rôles, et une distinction floue entre les fonctions administratives et standard, ce qui entraîne souvent des vulnérabilités de permissions. Les attaquants peuvent profiter de ces faiblesses pour accéder aux ressources d'autres utilisateurs ou à des fonctionnalités administratives.

Exemple : Une plateforme d'apprentissage en ligne propose divers cours aux étudiants. En raison de problèmes de conception de la plateforme, les étudiants peuvent accéder à des fonctionnalités réservées aux instructeurs en manipulant les URL ou les points de terminaison d'API. Par exemple, un étudiant pourrait découvrir qu'en changeant l'URL de /student/dashboard à /instructor/dashboard, il peut accéder au tableau de bord de l'instructeur, lui permettant de modifier le contenu des cours, de noter les devoirs ou même d'ajouter/supprimer des cours.

Recommandation :

• Refusez tout accès par défaut et exigez des autorisations explicites pour des rôles spécifiques. Avec APISIX, vous pouvez créer un consommateur ou un groupe de consommateurs pour donner des contrôles d'accès différents aux utilisateurs. Ensuite, le plugin d'authentification JWT peut être configuré pour inclure des informations de rôle dans le jeton JWT. Lorsqu'un utilisateur se connecte, le jeton JWT qu'il reçoit contiendra son rôle (student ou instructor). APISIX peut alors vérifier le rôle de l'utilisateur à partir du jeton JWT avant d'accorder l'accès à des fonctions spécifiques.
• Assurez-vous que les contrôleurs administratifs héritent d'un contrôleur qui implémente des vérifications d'autorisation basées sur les rôles des utilisateurs. Si vous utilisez API7 Enterprise, il permet aux administrateurs de limiter l'accès aux API à des utilisateurs/groupes particuliers et de configurer l'accès sur une base par requête et par utilisateur.

6. Accès non restreint aux flux métiers sensibles

Menace : Les flux métiers sensibles sont exposés sans évaluation des risques sur la manière dont la fonctionnalité pourrait nuire à l'entreprise si elle était utilisée de manière automatisée et excessive.

Exemple : En utilisant une combinaison de proxies et de scripts automatisés (bots), l'attaquant simule plusieurs utilisateurs réels effectuant des achats. Le script ajoute rapidement le produit au panier et termine le processus de paiement, épuisant le stock avant que les clients réels aient la chance de faire un achat. L'attaquant revend ensuite ces produits à un prix plus élevé sur d'autres plateformes. La plateforme de vente perd des revenus potentiels car elle ne peut pas vendre les produits aux clients réels au prix prévu.

Recommandation :

• Mettez en place l'empreinte digitale des appareils pour refuser le service aux appareils clients inattendus. APISIX peut être intégré à des plateformes de gestion des identités et des accès comme Auth0, Authgear, etc. pour activer différents mécanismes d'authentification, y compris les fonctionnalités de connexion biométrique sur les appareils.
• Utilisez des mécanismes de détection humaine comme des captchas ou des solutions biométriques avancées. Idem que ci-dessus.
• Analysez le flux utilisateur pour détecter les modèles non humains. Vous pouvez utiliser API7 Enterprise pour appliquer des facteurs d'authentification supplémentaires lorsqu'une requête est associée à des modèles non humains, comme des vitesses élevées entre différents lieux de connexion ou la détection de bots.
• Bloquez les adresses IP des sources malveillantes connues. APISIX dispose d'un plugin de restriction d'IP pour bloquer l'accès à partir d'une ou plusieurs adresses IP.

7. Falsification de requête côté serveur (SSRF)

Menace : Les attaques SSRF permettent à un attaquant de faire des requêtes vers des ressources internes du serveur, potentiellement en accédant aux réseaux internes, aux systèmes de fichiers ou même en exécutant des commandes. Cela se produit lorsqu'un point de terminaison d'API accepte une URL ou une partie de celle-ci en entrée et la récupère sans validation appropriée.

Exemple : Un point de terminaison d'API accepte une URL pour récupérer une image depuis Internet. Un utilisateur malveillant soumet une URL comme http://169.254.169.254/latest/meta-data/ (un point de terminaison de métadonnées typique dans les environnements cloud). Le service récupère l'URL, pensant qu'il s'agit d'une image, mais récupère plutôt des données sensibles comme des rôles IAM, des clés secrètes ou d'autres détails de configuration internes. L'attaquant utilise ensuite ces informations pour des attaques supplémentaires, comme l'élévation de privilèges ou des violations de données.

Recommandation :

• Validation des entrées - Validez et assainissez toujours les entrées. Évitez d'accepter des URL complètes provenant de sources non fiables. Avec APISIX, vous pouvez configurer un plugin de blocage d'URI pour appliquer des règles de blocage aux ressources internes.
• Liste blanche - Autorisez uniquement les connexions à des domaines ou IP connus et de confiance. Vous pouvez utiliser le plugin de restriction d'IP d'APISIX ou activer la restriction de référent pour une liste blanche de domaines ou de modèles d'URL acceptables. Toute URL ne correspondant pas à la liste blanche est rejetée.
• Segmentation du réseau - Assurez-vous que vos serveurs sont segmentés et que les ressources internes sensibles ne sont pas directement accessibles.

8. Mauvaise configuration de la sécurité

Menace : Cela se produit lorsqu'une API n'est pas configurée de manière sécurisée, exposant potentiellement des informations sensibles ou accordant des permissions inutiles. Les exemples incluent des messages d'erreur de journalisation révélant des détails du serveur, des méthodes HTTP inutiles activées ou des identifiants par défaut laissés inchangés.

Exemple : Un exemple simple pourrait être une API exposant accidentellement un répertoire .git, révélant le code source et l'historique des commits. Un autre exemple, un utilisateur malveillant, en utilisant votre plateforme, rencontre un message d'erreur. Au lieu d'un message d'erreur générique, il voit une trace de pile détaillée révélant la structure de la base de données, les versions des logiciels et les chemins de fichiers. En utilisant ces informations, il identifie des vulnérabilités potentielles dans la plateforme. De plus, en recherchant les mauvaises configurations courantes pour de telles plateformes, il essaie de se connecter avec le compte de test et réussit, lui accordant un accès administratif.

Recommandation :

• Audits réguliers - Passez régulièrement en revue et mettez à jour les configurations. Utilisez des outils automatisés pour scanner les mauvaises configurations courantes. Avec les plugins de journalisation d'APISIX, toutes les activités d'accès et système sont enregistrées. Toute activité inhabituelle, comme des échecs de connexion répétés ou l'accès à des points de terminaison restreints, peut être signalée pour examen.
• Principe du moindre privilège - Accordez uniquement les permissions nécessaires et évitez d'utiliser des paramètres trop permissifs.
• En-têtes de sécurité par défaut - APISIX applique des paramètres de sécurité par défaut avec des en-têtes de sécurité essentiels, comme la politique de sécurité du contenu (CSP) et la sécurité stricte du transport HTTP (HSTS), qui sont définis. Cela réduit le risque de certaines attaques basées sur le web.
• Masquage des erreurs - Assurez-vous que les messages d'erreur sont génériques et ne divulguent pas d'informations sensibles. APISIX peut être configuré pour masquer les messages d'erreur détaillés en utilisant le plugin de réécriture de réponse ou un plugin de masquage de données personnalisé.

9. Gestion inadéquate des inventaires

Menace : À mesure que les organisations grandissent, elles perdent souvent la trace de toutes leurs API, surtout s'il n'y a pas de gestion centralisée. Cela peut entraîner des API oubliées, obsolètes ou non protégées qui peuvent être exploitées.

Exemple : Il est courant que plusieurs versions d'API soient laissées sans surveillance. Les attaquants peuvent cibler des versions d'API obsolètes ou des points d'accès non corrigés. Ils peuvent également accéder de manière non autorisée via des vulnérabilités dans les connexions tierces.

Recommandation : Utilisez l'API Admin d'APISIX pour examiner régulièrement et désactiver les routes qui ne sont plus nécessaires et pour suivre toutes les versions d'API sans perturber les applications clientes. Le Portail API7 fournit un tableau de bord de gestion centralisé où toutes les API peuvent être surveillées et gérées. Une ancienne version d'une API pourrait encore être en cours d'exécution et n'est plus utilisée. Via le tableau de bord, cette API peut être identifiée et arrêtée sans aucun changement de code dans le service backend lui-même.

10. Consommation non sécurisée des API

Menace : Lors de l'intégration d'API tierces ou même de la consommation d'API internes, si cela n'est pas fait de manière sécurisée, l'action peut exposer l'application à des vulnérabilités présentes dans les API en amont.

Exemple : Prenons l'exemple d'une application mobile qui permet aux utilisateurs de surveiller leurs métriques de santé, comme la fréquence cardiaque, les habitudes de sommeil et l'activité physique. L'application n'a pas de validation stricte et de vérifications de sécurité lors de la consommation de ces API tierces. Un attaquant identifie que l'une des API intégrées de suivi nutritionnel est vulnérable et peut renvoyer des données malveillantes. Lorsque l'application récupère des suggestions de plans de repas à partir de cette API, elle récupère et traite involontairement des charges utiles malveillantes, entraînant des violations de données potentielles ou des dysfonctionnements de l'application.

Recommandation : Avant d'intégrer une API tierce, vérifiez si elle provient d'une source réputée et a subi des évaluations de sécurité.

• Gestion des erreurs - Gérez les réponses ou comportements inattendus des API consommées sans exposer de vulnérabilités.
• Validation des données - Validez et assainissez toujours les données reçues des API tierces. APISIX peut être intégré à des pare-feu d'applications web (WAF) pour inspecter et filtrer les données entrantes des API tierces. Cela peut détecter et bloquer les modèles ou charges utiles malveillants connus. Il est également possible pour vous d'activer TLS/mTLS pour les services en amont afin de garantir la sécurité du trafic pendant qu'il traverse le réseau interne.

Résumé

L'application des directives de sécurité suggérées par OWASP API 2023 fournit un point de départ fondamental pour sécuriser les API. L'utilisation des fonctionnalités de la passerelle APISIX simplifie ce processus et réduit considérablement le coût de mise en œuvre des mécanismes de prévention recommandés par l'OWASP.

Ressources connexes

• Sécuriser les API dans une passerelle API
• Authentification de la passerelle API
• Empêcher la fuite de données sensibles dans la passerelle API