Consommation illimitée de ressources

Qu'est-ce que Consommation illimitée de ressources?

Certains points de terminaison n'imposent aucune limite sur la quantité de travail qu'une requête peut exiger. Un point de terminaison de liste prend sa taille de page directement à partir de la requête et la transmet à la base de données sans maximum côté serveur, afin qu'un appelant puisse demander la table entière. Vous allez capturer le paramètre de limite contrôlé par l'appelant, reconstruire la requête demandant tout et regarder une réponse effacer l'intégralité du catalogue tout en épinglant la base de données. Le correctif limite la taille de la page côté serveur et l'associe à la pagination du curseur. Une nouvelle sonde renvoie un 200 OK limité.

Ce que vous apprendrez dans Consommation illimitée de ressources

• Reconnaître une consommation de ressources sans restriction où un point de terminaison n'impose aucune limite sur la quantité qu'une seule requête peut consommer, de sorte qu'un seul appel peut forcer un travail illimité.
• Comprendre qu'une taille de page fournie par l'appelant (ou nombre, taille ou profondeur) sans maximum côté serveur permet à une seule requête de renvoyer un ensemble de données complet à la fois
• Considérez qu'une taille de page non plafonnée est à la fois un vecteur de scraping de masse et un levier de déni de service, car une requête surdimensionnée épuise la mémoire et épingle une connexion à une base de données.
• Distinguez cela des failles d’accès au niveau des objets, de la sur-sérialisation des champs et des lacunes d’authentification ; ici, l'authentification est correcte et le contrôle manquant est une ressource liée par requête
• Appliquez le correctif : limitez la taille de page demandée à un maximum côté serveur, conservez la limite sur le serveur, paginez de grands ensembles de résultats avec un curseur et ajoutez une limitation de débit par client et par fenêtre de temps.

Consommation illimitée de ressources — Étapes de la formation

1. Un flux de navigation public

   Vendlo est une application de marché d'occasion : les membres répertorient les objets à vendre et tout le monde peut parcourir le catalogue. Aujourd'hui, Bob cible Vendlo. Il en attend deux choses : l'intégralité du catalogue en direct et ses prix, pour le revendre à un concurrent, et un moyen peu coûteux de renverser l'API s'il le décide. Il s'est inscrit en tant que membre ordinaire et ouvre le fil de navigation public pour voir comment il se charge.

2. Regardez la demande

   La grille que Bob regarde a été tirée des données que l'application a récupérées via l'API. Il montre 24 annonces et une note indiquant qu'il y en a beaucoup plus derrière elles. Bob ouvre les outils réseau du navigateur et recharge la page une fois pour capturer l'appel effectué par l'application pour créer le flux.

3. La taille de la page est celle de l'appelant

   Le rechargement a été capturé et la demande se trouve dans le panneau Réseau. Bob lit comment l'application a demandé sa page de listes.

4. Un quart de million derrière la page

   Bob ouvre la réponse renvoyée par le point de terminaison et lit ce qu'elle dit sur la taille du catalogue.

5. Demandez tout

   Bob reconstruit le même appel dans le testeur API et change une chose : au lieu d'une page de 24, il demande 250 000 listings en une seule requête. Si le serveur l'honore, un seul appel lui remettra l'intégralité du catalogue.

6. Une demande, tout le catalogue

   Le serveur a fait exactement ce qu'on lui demandait. La réponse raconte l’histoire de ce que cela a coûté.

7. Les boucles de la vitrine

   Cette requête est toujours en cours d'exécution, parcourant un quart de million de lignes et maintenant une connexion à la base de données tout le temps. Le pool de connexions de Vendlo est petit, donc même si cette requête lie une connexion, la vitrine publique ne peut pas en obtenir une propre. Bob recharge la page de Vendlo pour voir ce qu'un vrai acheteur verrait en ce moment.

8. De vrais acheteurs, exclus

   Le même point de terminaison qui vient de remettre à Bob l’intégralité du catalogue ne peut désormais plus servir un acheteur ordinaire. Le testeur API montre toujours son 200 avec le catalogue complet ; la vitrine à côté montre ce que tout le monde obtient.

9. Contrôle des connaissances

   Vous venez de voir une requête extraire un quart de million d'enregistrements et bloquer la base de données. Verrouillez pourquoi.

10. L'alerte débarque

    Vous possédez l'API du catalogue Vendlo. Du jour au lendemain, la surveillance a signalé une seule requête qui renvoyait l'intégralité du catalogue et maintenait une connexion à la base de données ouverte pendant neuf secondes, la latence de l'API augmentant sur chaque point de terminaison pendant son exécution. Les opérations de sécurité vous ont envoyé un e-mail.