Les codeurs conquièrent la série des 10 meilleures API de l'OWASP en matière de sécurité : manque de ressources et limitation du débit

En raison du manque de ressources et de la limitation du débit, la vulnérabilité des API agit presque exactement comme le décrit le titre. Chaque API dispose de ressources et de puissance de calcul limitées en fonction de son environnement. La plupart sont également tenus de répondre aux demandes des utilisateurs ou d'autres programmes leur demandant d'exécuter la fonction souhaitée. Cette vulnérabilité se produit lorsqu'un trop grand nombre de demandes arrivent en même temps et que l'API ne dispose pas de suffisamment de ressources informatiques pour traiter ces demandes. L'API peut alors devenir indisponible ou ne pas répondre aux nouvelles demandes.

Les API deviennent vulnérables à ce problème si leurs limites de débit ou de ressources ne sont pas définies correctement, ou si les limites ne sont pas définies dans le code. Une API peut alors être surchargée si, par exemple, une entreprise connaît une période particulièrement chargée. Mais il s'agit également d'une faille de sécurité, car les acteurs de la menace peuvent délibérément surcharger les API non protégées de requêtes afin de réaliser des attaques par déni de service (DDoS).

D'ailleurs, comment vous en sortez-vous avec les défis gamifiés liés à l'API jusqu'à présent ? Si vous souhaitez tester vos compétences en matière de gestion d'une vulnérabilité limitant le débit dès maintenant, entrez dans l'arène :

Maintenant, allons un peu plus loin.

Quels sont quelques exemples de vulnérabilité liée au manque de ressources et à la limitation du débit des API ?

Cette vulnérabilité peut se faufiler dans une API de deux manières. La première est lorsqu'un codeur ne définit tout simplement pas quels devraient être les taux d'accélération d'une API. Il existe peut-être un paramètre par défaut pour les taux d'accélération quelque part dans l'infrastructure, mais s'y fier n'est pas une bonne politique. Au lieu de cela, chaque API doit avoir ses tarifs définis individuellement. Cela est d'autant plus vrai que les API peuvent avoir des fonctions et des ressources disponibles très différentes.

Par exemple, une API interne conçue pour répondre aux besoins de quelques utilisateurs seulement peut avoir un taux d'accélération très faible et fonctionner parfaitement. Mais une API destinée au public faisant partie d'un site de commerce électronique en direct aurait très probablement besoin d'un taux exceptionnellement élevé défini pour compenser la possibilité d'une augmentation du nombre d'utilisateurs simultanés. Dans les deux cas, les taux d'étranglement doivent être définis en fonction des besoins attendus, du nombre d'utilisateurs potentiels et de la puissance de calcul disponible.

Il peut être tentant, en particulier pour les API qui seront probablement très occupées, de fixer les tarifs à un niveau illimité afin d'essayer de maximiser les performances. Cela pourrait être accompli avec un simple bout de code (à titre d'exemple, nous utiliserons le Framework Python Django REST) :

« DÉBIT_D'ÉTRANGLEMENT PAR DÉFAUT : {
« anon : Aucun,
« utilisateur : Aucun

Dans cet exemple, les utilisateurs anonymes et ceux connus du système peuvent contacter l'API un nombre illimité de fois, quel que soit le nombre de demandes au fil du temps. C'est une mauvaise idée, car quelle que soit la quantité de ressources informatiques dont dispose une API, les attaquants peuvent déployer des éléments tels que des botnets pour éventuellement la ralentir ou la mettre complètement hors ligne. Dans ce cas, les utilisateurs valides se verront refuser l'accès et l'attaque sera couronnée de succès.

Éliminer le manque de ressources et les problèmes de limitation des taux

Chaque API déployée par une organisation doit avoir ses taux d'accélération définis dans son code. Cela peut inclure des éléments tels que les délais d'exécution, la mémoire maximale autorisée, le nombre d'enregistrements par page qui peuvent être renvoyés à un utilisateur ou le nombre de processus autorisés au cours d'une période définie.

À partir de l'exemple ci-dessus, au lieu de laisser les taux de limitation ouverts, ils pourraient être définis de manière précise avec des taux différents pour les utilisateurs anonymes et connus.

« DÉBIT_D'ÉTRANGLEMENT PAR DÉFAUT : {
« anon : config (« THROTTLE_ANON », par défaut = 200 par heure),
« user : config (« THROTTLE_USER », par défaut = 5000/heure)

Dans le nouvel exemple, l'API limiterait les utilisateurs anonymes à 200 requêtes par heure. Les utilisateurs connus qui sont déjà approuvés par le système disposent d'une plus grande marge de manœuvre à raison de 5 000 demandes par heure. Mais elles sont également limitées pour éviter une surcharge accidentelle aux heures de pointe ou pour compenser si un compte utilisateur est compromis et utilisé pour une attaque par déni de service.

En guise de dernière bonne pratique à prendre en compte, il est conseillé d'afficher une notification aux utilisateurs lorsqu'ils ont atteint les limites de limitation, ainsi qu'une explication de la date à laquelle ces limites seront réinitialisées. De cette façon, les utilisateurs valides sauront pourquoi une application rejette leurs demandes. Cela peut également être utile si des utilisateurs valides effectuant des tâches approuvées se voient refuser l'accès à une API, car cela peut signaler au personnel des opérations que la limitation doit être augmentée.

Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.