Les API sont essentielles à la réussite d’une application, mais ces petits bouts de code représentent un vecteur d’attaque extrêmement populaire.
Les API permettent aux applications et aux utilisateurs d’accéder facilement aux données numériques et aux services d’une organisation, et d’interagir avec eux. Elles sont si populaires qu’elles représentent environ 83 % du trafic Internet mondial. Cependant, les API offrent également des points d’entrée ouverts dans une infrastructure informatique bien gardée. Sans protection adéquate, des acteurs malveillants peuvent facilement s’implanter dans un réseau via une API. En fait, 20 % des personnes interrogées lors d’une enquête ont déclaré avoir subi une violation de données au cours de l’année passée en raison de vulnérabilités dans la sécurité des API.
Les équipes de sécurité doivent se concentrer sur l’élimination des cinq vulnérabilités suivantes, qui – malgré leur notoriété – sont encore souvent présentes et exploitables dans les API d’aujourd’hui.
1. Authentification faible
Vulnérabilité
L’authentification vérifie qu’un utilisateur ou un appareil est bien celui qu’il prétend être. Cela empêche les personnes ou les appareils sans les autorisations appropriées d’accéder à des informations et des ressources. Si le processus d’authentification est facile à contourner ou à compromettre – comme des mots de passe faibles ou facilement devinables – un attaquant peut se faire passer pour un utilisateur légitime de manière ponctuelle ou permanente.
Solution
Mettez en place une politique stricte de mots de passe et une authentification à plusieurs facteurs pour l’accès aux ressources sensibles, comme les comptes bancaires, afin de réduire la possibilité de prise de contrôle d’un compte. Plus important encore, assurez-vous que les processus de mot de passe et d’authentification fonctionnent comme prévu. Cela nécessite des tests approfondis, en particulier sur la gestion des cookies de session, car ils peuvent facilement introduire des vulnérabilités exploitables. Les cookies de session doivent être totalement aléatoires et imprévisibles et se rafraîchir après chaque connexion réussie ou changement de niveau d’accès. Toute tentative d’accès à des ressources sans être correctement authentifiée doit recevoir le code de statut de réponse « 401 Non autorisé ». Limitez le nombre de tentatives de connexion infructueuses, après lesquelles le compte est verrouillé. Utilisez des clés API pour identifier les utilisateurs, mais pas pour les authentifier ou les autoriser, car les clés sont trop facilement exposées et mal utilisées.
2. Autorisation d’objet manquante
Vulnérabilité
Souvent désignée sous le terme d’autorisation d’objet cassée, elle survient lorsque les vérifications côté serveur ne confirment pas que le demandeur est autorisé à accéder ou à modifier les données et les objets listés dans la demande. Par exemple, un attaquant pourrait changer l’ID utilisateur dans une demande, pour voir si des informations concernant un autre utilisateur sont renvoyées, ce qui pourrait conduire à un accès non autorisé aux données. Cette vulnérabilité a été notablement découverte dans une API d’Uber en 2019 qui permettait aux conducteurs d’accéder aux données d’autres conducteurs simplement en changeant l’ID utilisateur. Si les fonctions de modification des données manquent également de contrôles d’autorisation correctement mis en œuvre, les attaquants pourraient être en mesure de modifier ou de supprimer des données et même de prendre totalement le contrôle d’un compte d’un autre utilisateur.
Solution
Les identifiants pour les objets devraient être aléatoires et imprévisibles plutôt que des valeurs séquentielles prévisibles qui peuvent être facilement devinées. Les vérifications côté serveur devraient également confirmer ce qui suit :
L’utilisateur est autorisé à accéder à l’objet demandé.
L’utilisateur dispose des autorisations nécessaires pour exécuter une opération particulière sur l’objet.
3. Vulnérabilités d’injection
Vulnérabilité
Lorsqu’une API reçoit des données fournies par l’utilisateur, mais qu’elle ne les analyse et ne les valide pas avant de traiter la demande, les attaquants peuvent envoyer des données ou des commandes malveillantes pour déclencher une attaque par injection. Les requêtes de base de données et les commandes d’OS peuvent toutes être potentiellement exécutées via XML, JSON, des injections cross-site scripting (XSS), SQL et NoSQL pour accéder à des données ou exécuter des commandes malveillantes sans autorisation.
Solution
Plutôt que de créer vos propres fonctions pour valider et assainir les données entrantes, profitez des nombreuses bibliothèques spécialisées mettant en œuvre des listes d’autorisation, afin de garantir que les données sont du type et de la longueur requis, et de supprimer les caractères ou paramètres inattendus et les commandes d’injection connues. Exécutez ces vérifications contre chaque demande entrante.
4. Exposition de données excessive
Vulnérabilité
Les réponses d’une API à une requête renvoient souvent beaucoup plus de données que nécessaire pour satisfaire la requête. Cela se produit généralement parce qu’il est plus simple pour un développeur d’écrire un code qui renvoie une ligne entière d’une table plutôt que seulement le(s) champ(s) spécifique(s) requis. Par exemple, une page de profil sur une application de messagerie peut afficher le nom et l’âge d’une personne, mais souvent, les requêtes d’API renvoient toutes les informations stockées sur l’utilisateur plutôt que simplement le nom et l’âge de cet utilisateur, calculé à partir de sa date de naissance. Bien que l’application puisse filtrer la réponse et n’afficher que le nom et l’âge, il est facile pour les attaquants de lire et de collecter d’autres détails renvoyés dans la requête, y compris des informations personnellement identifiables, telles que la date de naissance, l’adresse e-mail et la localisation. Cette exposition de données sensibles peut enfreindre les règles de politique d’accès aux données et les réglementations de conformité.
Solution
Les réponses des API ne devraient renvoyer que les données nécessaires pour satisfaire une demande ; les requêtes de base de données effectuées par l’API devraient sélectionner uniquement l’enregistrement(s) et le(s) champ(s) pertinents. La documentation d’une API devrait indiquer quelles données sont nécessaires pour satisfaire une demande, et il devrait donc être facile de s’assurer que les requêtes de base de données correspondent aux champs et aux enregistrements demandés. N’oubliez pas que l’application cliente ne peut filtrer que les données visibles pour l’utilisateur, pas les données qu’elle reçoit.
5. Sécurité mal configurée
Vulnérabilité
Les API fonctionnent sur des infrastructures complexes, avec des ressources qui sont automatiquement augmentées ou réduites en fonction de la demande. Si les contrôles de sécurité ne sont pas correctement configurés à chaque couche, les données sensibles et les systèmes peuvent être à risque. Les erreurs de configuration courantes comprennent des appareils et des applications non patchés, des configurations par défaut non sécurisées, des données non chiffrées en transit, et des services de stockage et de services en cloud ouverts et non sécurisés.
Solution
Les API ne devraient exposer que des points de terminaison HTTPS. Cependant, comme ces points de terminaison HTTPS sont ouverts à Internet, il est également essentiel que la limitation de débit soit correctement appliquée pour contrôler le taux de requêtes et le nombre de ressources demandées. Sinon, ils sont ouverts aux attaques par déni de service (DoS) et aux attaques par force brute. Désactivez les méthodes HTTP inutilisées, comme TRACE, et ajoutez les en-têtes de sécurité de réponse HTTP appropriés, tels que X-Content-Type-Options: nosniff pour prévenir les attaques XSS et X-Frame-Options: deny afin d’empêcher les tentatives de détournement de clics. De plus, tous les messages d’erreur qu’une requête API génère ne devraient inclure que des informations minimales pour garantir qu’aucune donnée sensible sur le système ne soit révélée, comme les détails techniques de l’erreur.
Comment améliorer la sécurité globale d’une API
La clé pour garantir que les API n’ouvrent pas de canaux vulnérables dans l’infrastructure informatique est de se concentrer sur la protection des ressources auxquelles elles accèdent et des actions que les utilisateurs peuvent effectuer sur elles. Cela signifie instaurer des contrôles d’authentification et d’autorisation non pas une seule fois, mais de manière continue avec une stratégie de confiance zéro.
Des audits de sécurité programmés des conteneurs, des microservices, du stockage en cloud et des pipelines d’intégration continue/livraison continue sont essentiels.
Utilisez la modélisation des menaces pour façonner la conception de vos API afin d’intégrer des contrôles de sécurité, tels que des fonctionnalités robustes de contrôle d’identité et de gestion des accès, dès le début de la phase de construction pour atténuer les risques identifiés. Testez que ces contrôles fonctionnent dans le workflow DevOps.
Les attaquants peuvent passer des jours à effectuer des reconnaissances et des explorations avant de réussir à exploiter une API dans le cadre d’une cyberattaque. Les organisations devraient déployer une journalisation et une surveillance complètes du trafic API pour repérer et arrêter les attaques, avant qu’elles ne causent des dommages. Travaillez à partir d’un inventaire d’APIs à jour, et révisez régulièrement les contrôles de sécurité et les configurations pour vous assurer qu’ils restent appropriés et efficaces.
La sécurité basée sur le périmètre hérité n’est pas suffisante pour bloquer les attaques dans les infrastructures API hautement distribuées. Des audits de sécurité programmés des conteneurs, des microservices, du stockage en cloud et des pipelines d’intégration continue/livraison continue sont essentiels pour éviter que des points d’accès inutilisés ou oubliés ne soient pas protégés contre une exploitation.
Mettre l’accent sur la sécurité plutôt que sur la rapidité lors du développement peut également constituer un grand pas en avant pour éliminer les vulnérabilités de sécurité des API qui continuent de mettre les données et les utilisateurs en danger, avant qu’elles n’atteignent la version de production.
Pour approfondir sur Gestion des vulnérabilités et des correctifs (patchs)
