10 points de contrôle pour vérifier la sécurité de ses API
En 2019, l'Open Web Application Security Project (OWASP), communauté libre et ouverte à tous, publiait son TOP 10 des vulnérabilités liées à l'usage des API. Tirés de ce document référence, voici les dix points de contrôle à mettre en place pour encadrer leur utilisation mais aussi leur développement.
Vérifier les autorisations au niveau de chaque objet
Les contrôles d'autorisation au niveau des objets doivent être pris en compte pour chaque fonction qui accède à une source de données, via une entrée de l'utilisateur. "Imaginons une messagerie instantanée avec votre banque. Vos messages sont sûrement stockés pour les historiser avec un ID dédié qui irait, mettons de 1 à 10, si vous avez échangé 10 messages. Les ID des messages entre votre banque et un autre client commenceront par 11 puis 12. Si une API permet de récupérer un message en fonction de son ID, GET /message/id=1 ou 2 ou 3 ou n, elle vous permettra également de lire d'autres messages qui ne vous sont pas destinés, si rien n'a été mis en place pour vous autoriser uniquement la lecture des messages 1 à 10", illustre Jordan Afonso, développeur senior d'APIs.
Soigner l'authentification utilisateur
Mal mis en œuvre, les mécanismes d'authentification offrent aux attaquants la possibilité de compromettre les jetons de connexion ou d'exploiter les défauts de mise en œuvre pour usurper l'identité d'autres utilisateurs. Dans l'usage, le niveau d'authentification dépendra de la sensibilité des données, du contexte et des habitudes de l'utilisateur. "Dans le cas où on souhaite sécuriser l'accès à une donnée d'une API météo, par exemple, si ce secret est divulgué, d'autres utilisateurs pourront accéder aux données météorologiques, ce qui n'est pas très sensible. Pour protéger l'accès à des informations personnelles, bancaires, médicales ou à un service gérant l'alimentation électrique d'une zone, on mettra en place une stratégie bien plus poussée", explique Jordan Afonso. L'état de l'art impose d'utiliser une authentification multifacteur pour toutes les opérations sensibles.
Sélectionner les données à afficher
Les développeurs d'API doivent tenir compte de la sensibilité individuelle des propriétés de chaque objet et ne pas laisser à leur client la responsabilité du filtrage de celles à afficher à l'utilisateur. Le risque est que des informations autres que celles nécessaires soient véhiculées. "Lorsqu'on designe une API, on fait en sorte de ne mettre à disposition que le strict nécessaire. Par exemple, nous avons audité l'API d'un client dans le retail pour une application qui avait besoin de connaître la boutique préférée de ses clients. Or, l'API renvoyait également l'adresse du client, ses coordonnées complètes ainsi que son moyen de paiement favori ! L'application cliente avait donc accès à trop de données par rapport au besoin initial et, dans les faits, on ne peut pas demander aux développeurs de l'application de faire le tri. C'est le job de l'API !", affirme Jordan Afonso.
Limiter les ressources et le débit
L'absence de restriction sur la taille ou le nombre de ressources peut avoir un impact sur les performances du serveur mais, surtout, permettre à des pirates de réaliser un déni de service (DoS) ou de recourir au "brute force" pour s'attaquer aux identifiants des utilisateurs. Dans le cas du DoS ou DDoS, si plusieurs machines réalisent l'attaque, une grande quantité de données va être demandée à un serveur. Dans le deuxième cas de figure, le "brute force" consiste à tester toutes les combinaisons possibles pour trouver des identifiants. "S'il n'y a qu'un identifiant (avec API Key, par exemple) et que le serveur nous indique à chaque fois que l'API Key est incorrecte, on peut réessayer un nombre infini de fois et on finira par tomber sur la bonne clé. Il est possible de mettre en place plusieurs contre-mesures, comme une authentification plus forte, avec un dispositif MFA, par exemple. Il est plus difficile de "brute-forcer" deux barrages.", ajoute Jordan Afonso. Il est également possible de limiter le nombre d'essais infructueux ou de ne pas indiquer au client la raison de sa non-autorisation.
Modérer la granularité des accès
Les politiques de contrôle d'accès trop complexes avec des hiérarchies, des groupes et des rôles différents et une séparation peu claire entre les fonctions administrateur et user ont tendance à générer des failles dans les autorisations. On parle ici du principe de moindre privilège. S'il existe plusieurs niveaux d'autorisation d'accès, il est recommandé de réduire au strict minimum ce niveau pour chaque utilisateur. Par exemple, sur une page Google Doc, on peut être en mode Édition (tout faire sur le document), en mode Suggestion (suggérer uniquement des modifications qui doivent être validées par l'auteur), en mode Affichage, ou l'on peut seulement lire le document. "Autre exemple d'un client retail : une des fonctionnalités de leur API permettait de retirer des articles du catalogue en ligne et n'a pas été gérée au niveau de l'accès développeur du service client, les autorisant ainsi à modifier le catalogue, ce qui a causé de sérieux dégâts, suite à quelques mauvaises manipulations", raconte Jordan Afonso.
Eviter les affectations de masse
Lier les données fournies par le client (par exemple, Json) aux modèles de données, sans filtrage approprié des propriétés sur la base d'une liste d'autorisations, peut conduire à une affectation massive. Ce qui est à éviter car un attaquant peut modifier, écraser d'autres données en devinant les propriétés des objets, en explorant d'autres points de terminaison de l'API, en lisant la documentation ou encore en fournissant des propriétés d'objets supplémentaires dans les charges utiles des requêtes.
Vérifier la configuration de la sécurité
La mauvaise configuration de la sécurité résulte généralement de la configuration par défaut, et donc non sécurisée, de configurations incomplètes ou ad hoc, d'un stockage en nuage ouvert, d'entêtes HTTP mal configurés, de méthodes HTTP inutiles, d'un partage de ressources inter-origines (CORS) permissif et de messages d'erreur verbeux contenant des informations sensibles.
Anticiper les injections de code
Les failles d'injection, telles que SQL, NoSQL, Command Injection, etc. se produisent lorsque des données non fiables sont envoyées à un interpréteur, dans le cadre d'une commande ou d'une requête. Les données malveillantes de l'attaquant peuvent inciter l'interpréteur à exécuter des commandes involontaires ou à accéder à des données sans autorisation appropriée.
Bien gérer et inventorier ses actifs
Les API ont tendance à exposer plus de points de terminaison que les applications web traditionnelles, ce qui rend très importante une documentation appropriée et sa mise à jour. Un inventaire des hôtes et des versions d'API déployées joue également un rôle important pour atténuer les problèmes tels que les versions d'API dépréciées et les points de terminaison de débogage exposés. "Un des nouveaux enjeux est clairement lié au volume. Comment passer d'une dizaine d'API à des centaines, avec le risque d'en manquer une et donc d'avoir un vecteur d'entrée, si elle est mal codée, mal configurée ou mal gérée ? L'inventaire le plus précis de ces API est un vrai sujet. Le vecteur de compromission type ransomware cherche des points d'entrée autres que le mail, notamment au travers de services qui sont connectés et en écoute sur internet.", explique Michel Vujicic, CTO de i-Tracing.
Mettre en place une gestion des logs efficace
L'insuffisance de la journalisation et de la surveillance, associée à l'absence ou à l'inefficacité de l'intégration avec la réponse aux incidents, permet aux attaquants d'attaquer davantage les systèmes, de maintenir la persistance, de passer à d'autres systèmes pour altérer, extraire ou détruire les données. La plupart des études sur les brèches démontrent que leur temps de détection est supérieur à 200 jours, et qu'elles sont généralement détectées par des parties externes plutôt que par des processus ou une surveillance internes. Or, la lenteur de détection et de remédiation est directement corrélée à l'impact financier.