La vulnérabilité de consommation illimitée de ressources a remplacé le manque de limitation des ressources et de débit dans le Top 10 de la sécurité des API de l'OWASP, mais bien que le nom ait changé, la vulnérabilité reste globalement la même.
Les requêtes API consomment des ressources telles que le réseau, le processeur, la mémoire et le stockage. Le nombre de ressources nécessaire pour satisfaire une requête dépend fortement des données saisies par l'utilisateur et de la logique métier du point de terminaison.
Les API n'imposent pas toujours de restrictions sur la taille ou le nombre de ressources pouvant être demandées par le client ou l'utilisateur, créant ainsi des vulnérabilités de sécurité qui peuvent non seulement impacter les performances du serveur API, menant à un déni de service (DoS), mais aussi ouvrir la porte à des attaques par force brute et par énumération contre les API fournissant des fonctionnalités d'authentification et de récupération de données. Cela inclut des menaces automatisées telles que le craquage d'identifiants et de jetons, entre autres.
Impact potentiel de la consommation illimitée de ressources
Pour déterminer l'impact potentiel de la consommation illimitée de ressources — classée quatrième dans le Top 10 de la sécurité des API de l'OWASP — il est préférable de diviser l'impact de ce problème en deux sous-composantes :
- En ce qui concerne l'absence de limitation des ressources, un attaquant peut concevoir un appel API unique capable de submerger une application, impactant ses performances et sa réactivité, voire la rendant totalement indisponible. Ce type d'attaque est parfois appelé DoS au niveau applicatif. Ces attaques n'affectent pas seulement la disponibilité ; elles peuvent également exposer le système, l'application ou l'API à des attaques par authentification et à une fuite excessive de données.
- En ce qui concerne l'absence de limitation de débit, un attaquant peut concevoir et soumettre des volumes élevés de requêtes API pour saturer les ressources système, forcer des identifiants de connexion, énumérer rapidement de grands ensembles de données ou exfiltrer d'importantes quantités d'informations.
À quoi ressemble une consommation illimitée de ressources ?
Dans l'exemple ci-dessus concernant l'absence de limite de ressources, l'attaquant a augmenté les valeurs max_return et page_size du filtre de recherche de 250 à 20 000. Cette augmentation entraînerait le renvoi d'un nombre excessif d'éléments par l'application en réponse à une requête. Cela pourrait également ralentir l'application ou la rendre indisponible pour tous les utilisateurs.
Exemple concret : l'attaque DDoS sur le portail fiscal polonais
Un exemple très connu de ce type d'attaque est l'attaque par déni de service distribué (DDoS) ciblant les API. Un exemple récent montre comment le portail fiscal principal de la Pologne a été rendu indisponible pour les citoyens polonais en raison d'une attaque de cette catégorie, où des pirates ont pu exploiter les ressources supportant les API du service fiscal central pour le rendre indisponible pendant plusieurs heures.
Alors que les responsables du gouvernement polonais ont rapidement pointé du doigt des pirates russes dans le contexte de la guerre en Ukraine, cette attaque démontre à quel point le paysage social et politique actuel rend la cybersécurité, et la sécurité des API en particulier, encore plus cruciale pour les entreprises comme pour les institutions gouvernementales.
Pourquoi les outils existants ne vous protègent pas contre les attaques par consommation illimitée de ressources
Les contrôles de sécurité traditionnels comme les WAF, les passerelles API, et d'autres mécanismes de proxy offrent généralement une limitation de débit basique ou statique, difficile à appliquer à grande échelle. Les équipes de sécurité peuvent ne pas connaître suffisamment la conception de l'application pour définir ce qui est « normal » et ainsi imposer des limites permettant de contrer les attaquants sans nuire aux fonctionnalités métier. Les WAF et les passerelles API manquent du contexte nécessaire pour indiquer aux équipes de sécurité quelle valeur normale devrait être attribuée à un paramètre d'API, et ils passeront à côté des attaques où un attaquant manipule la valeur d'un seul paramètre d'API pour saturer l'application. Ces proxys peuvent également ne couvrir que le trafic entrant, par opposition au trafic sortant (requêtes et réponses).
Comment protéger vos API contre les menaces de consommation illimitée de ressources
Une solution de sécurité des API doit être capable d'identifier les appels aux points de terminaison API et les modifications des valeurs des paramètres API qui sortent de l'usage normal. Cela s'effectue en analysant tout le trafic API pour établir une base de référence du comportement type et en identifiant les écarts par rapport à cette base.
Dans l'exemple ci-dessus, une solution de sécurité des API aura établi une base de référence pour les valeurs des paramètres max_return et page_size et identifiera qu'une valeur de 20 000 est anormale. La solution pourrait alors alerter et bloquer un attaquant qui conçoit des requêtes API s'écartant de cette base de référence.
Pour en savoir plus sur la façon dont Salt peut aider à protéger votre organisation contre les risques liés aux API, vous pouvez contacter un représentant ou planifier une démonstration personnalisée.