Récemment, on m'a demandé si un CDN à haute sécurité ne pouvait pas empêcher les attaques d'API. C'est une bonne question, qui montre que les gens commencent enfin à se préoccuper de la sécurité réelle des entreprises - après tout, de nos jours, il suffit d'un crawler ou d'appels malveillants pour que l'interface s'effondre, sans parler de ceux qui visent spécifiquement les attaques par CC de l'API et la pénétration par injection.
J'en arrive directement à la conclusion : oui, mais il ne faut surtout pas ouvrir un CDN pour tout. Il faut comprendre que le CDN haute défense est essentiellement un système de “nettoyage du trafic + planification intelligente”, et que la protection de l'API appartient à une catégorie plus raffinée de WAF (Web Application Firewall). De nombreux fournisseurs annoncent “une clé pour protéger l'API”, en fait, derrière une pile de configurations empilées, si l'on en croit les mots publicitaires, il n'y a pas loin de la coupe aux lèvres.
Je commencerai par un point : beaucoup de gens pensent qu'en achetant un CDN à haute défense, l'API sera automatiquement en sécurité. À la suite de l'attaque, il s'est avéré que la réponse de l'interface était lente comme un escargot, un journal de vérification, toutes les demandes malveillantes contournent les règles de mise en cache, directement à la station source. Il ne s'agit pas vraiment d'un problème de CDN, mais vous n'avez pas dit au CDN “quelle est l'API” “comment l'empêcher”.
En quoi une attaque par API diffère-t-elle d'une attaque par Internet classique ?
Les API sont souvent au cœur de l'activité, avec des interactions de données fréquentes, et de nombreuses requêtes dynamiques qui ne peuvent pas compter sur la mise en cache pour acheminer le trafic. Les attaquants aiment se concentrer sur l'API, car une fois que vous avez contourné la protection, vous pouvez directement obtenir les données et même lever le droit. J'ai testé, sans limiter le taux de l'interface de connexion, une seule requête IP des centaines de fois par seconde, l'unité centrale du serveur a directement explosé - et il ne s'agit là que d'une attaque primaire.
Plus impitoyable est le type d'attaque lente à faible fréquence, simulant le comportement normal de l'utilisateur, toutes les quelques secondes pour ajuster la clé API. Cette demande semble inoffensive, mais un jour peut consommer des centaines de milliers de requêtes de base de données, et le WAF traditionnel est difficile à trouver. Par conséquent, la protection de l'API doit être “raffinée”, se contenter des listes noires d'adresses IP et de la protection CC de base n'est absolument pas suffisant.
Comment protéger les API avec un CDN à haute défense ? L'essentiel tient en trois points : l'identification, les règles et les liens.
Tout d'abord, vous devez indiquer au CDN quels chemins sont des API. Par exemple, votre interface de connexion utilisateur est /api/v1/loginLa demande de commande est /graphqlIl faut les indiquer explicitement au CDN : “Ce sont des interfaces, ne les traitez pas comme des ressources statiques”. L'avantage est que les principaux fournisseurs prennent en charge la correspondance des chemins et peuvent même remplacer le routage dynamique par des expressions régulières.
Par exemple, dans la console CDN5, vous pouvez configurer les règles de chemin d'accès à l'API comme suit :
Cet ensemble de règles signifie que toutes les interfaces API doivent accepter un maximum de 100 requêtes par minute, avec pas plus de 20 courtes rafales. Après avoir dépassé cela, il ne s'agit pas d'un blocage direct d'IP, mais d'une fenêtre CAPTCHA - après tout, il est pire de blesser accidentellement un utilisateur réel que de laisser un robot s'en sortir.
Mais il ne suffit pas de limiter le flux, il faut aussi se protéger contre les paramètres malveillants et les attaques par injection. C'est là que les règles WAF entrent en jeu. Par exemple, pour l'injection SQL, vous pouvez configurer des règles personnalisées dans la console de CDN07 :
Attention, ne copiez pas mes règles directement ici ! Dans l'environnement réel, il faut s'adapter à l'activité, sinon on risque de tuer par erreur la requête normale. J'ai vu un projet de commerce électronique, l'interface de recherche de produits avec le mot clé “union” (comme “alliance de marques”), les résultats ont été directement bloqués par le WAF, une grande blague.
Comparaison des capacités de protection de l'API de différents fournisseurs de CDN
J'ai utilisé pas moins de dix CDN et, pour être honnête, le niveau de chacun varie. Par exemple, la protection de l'API de CDN5 est plus détaillée, prend en charge la détection basée sur le corps JSON et peut même analyser la structure des requêtes GraphQL ; tandis que l'avantage de CDN07 réside dans l'intelligence globale des menaces, qui peut relier les modèles d'attaque d'autres clients et bloquer les IP malveillantes à l'avance.
Toutefois, certains petits fournisseurs (je ne les nommerai pas) de “protection des API” ne sont qu'un gadget, par essence, ou une protection CC sous un autre nom, même POST Body ne peut pas être détecté. Si vous utilisez ce type de protection, cela équivaut à creuser un trou pour la sécurité de l'API.
Récemment, j'ai également testé les nœuds d'outre-mer de 08Host et j'ai découvert que leur stratégie de protection pour les API est un peu intéressante : non seulement elle prend en charge la limitation de flux et le WAF, mais elle peut également ajuster dynamiquement sa stratégie en fonction du code d'état de retour de l'interface. Par exemple, si une interface renvoie soudainement un grand nombre d'erreurs 500, le système déclenchera automatiquement un meltdown pour éviter l'effet d'avalanche - cette fonctionnalité est particulièrement utile pour l'architecture des microservices.
Configuration pratique : trois étapes pour construire un système de protection de l'API
La première étape consiste sans aucun doute à trier les actifs de l'API. C'est quelque chose qui semble élémentaire, mais 80 % des équipes ne le font tout simplement pas. Vous devez lister toutes les interfaces qui sont ouvertes au public, y compris les chemins, les méthodes (GET/POST), les paramètres et les lignes de base du trafic normal. Je recommande d'exporter directement avec Swagger ou la spécification OpenAPI, sinon le tri manuel peut être épuisant.
La deuxième étape consiste à définir des stratégies de protection pour les différentes interfaces. Les interfaces sensibles (telles que la connexion, le paiement) doivent limiter strictement le flux et la détection de paramètres complets, les interfaces publiques (telles que la liste des produits) peuvent être assouplies pour limiter le flux, mais avec une fonction anti-crawler. Un exemple :
La troisième étape est la surveillance des journaux et l'itération.CDN journaux de protection doivent être docked système SIEM ou plate-forme de surveillance auto-construit, en se concentrant sur les faux kills et les événements de contournement. J'ai précédemment compté sur la pile ELK pour faire un Kanban en temps réel, a constaté qu'un certain crawler spécifiquement le matin à 4:00 crawl API à faible fréquence, et a ensuite ajouté les règles de dimension temporelle pour arrêter complètement.
Ne marchez jamais dans ces nids de poule !
Certaines personnes aiment fixer la valeur limite du flux à un niveau extrêmement bas dès qu'elles se présentent, ce qui a pour conséquence que les utilisateurs réels ont fait sauter le CAPTCHA en masse pendant la campagne, et que l'expérience s'est directement effondrée. La bonne approche consiste à commencer par observer pendant un certain temps, en fonction de la distribution réelle du trafic, pour fixer le seuil - par exemple, prendre le volume moyen de requêtes de 3 fois comme ligne de déclenchement.
N'oubliez pas non plus que le CDN n'est qu'une couche de protection, et que les API clés doivent être vérifiées deux fois au niveau de la couche métier. Par exemple, l'interface permettant de modifier les données de l'utilisateur, vous devez vérifier le jeton d'identité et les privilèges d'exploitation. Lors d'un test de pénétration, j'ai trouvé une faille : le niveau CDN a placé la requête, mais le serveur n'a pas vérifié si l'identifiant de l'utilisateur appartient à la session en cours, ce qui a eu pour conséquence d'outrepasser le droit d'accès.
Il y a également des problèmes de certificat et de cryptage. L'API doit être entièrement liée à HTTPS et doit mettre à jour le certificat régulièrement. J'ai vu trop de tragédies où le CDN ne parvient pas à retourner à la source à cause d'un certificat expiré, et l'API est toute 503. Maintenant que Let's Encrypt peut renouveler automatiquement le certificat, il n'y a plus aucune raison de faire cette erreur.
En résumé.
Un CDN à haute défense protège contre les attaques d'API, mais nécessite une configuration proactive et une optimisation continue. L'idée de base est la suivante : identifier les actifs de l'API → établir des règles affinées → surveiller les itérations. Lors de la sélection des fournisseurs, concentrez-vous sur la précision de détection du WAF, les dimensions de limitation des flux et les capacités de journalisation, comme CDN5 et CDN07 sont dans le premier niveau, et 08Host est adapté à des scénarios spécifiques.
Enfin, une chose est sûre : la sécurité des API n'est pas une solution unique, les méthodes d'attaque évoluent tous les jours. Même sur le meilleur CDN, vous devez effectuer régulièrement des tests de pénétration et des audits de règles. Sinon, lorsque la fuite de données et ensuite la remédiation, ce n'est pas un changement de configuration qui peut être résolu.
