L’attaque que vous ne pouvez pas arrêter dans votre application

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Une grande variété d’attaques basées sur HTTP peuvent (et doivent) être bloquées au sein de votre application. Le Top 10 de l’OWASP constitue un excellent exemple de techniques d’attaque qui peuvent être à la fois détectées et empêchées depuis n’importe quelle application. Une multitude d’outils, notamment d’analyse statique et dynamique ainsi que de tests d’intrusion, permettent d’éviter que ces vulnérabilités n’atteignent la production. À condition, bien sûr, que ces tests de sécurité soient intégrés en amont dans le processus CI/CD plutôt que d’être relégués à la toute dernière étape avant d’actionner l’interrupteur (ou de basculer les bits, pour ainsi dire) qui rend l’application accessible aux utilisateurs.

Même si vous avez éliminé toutes les vulnérabilités potentielles détectées lors du développement, les applications restent exposées. En effet, certaines attaques ne peuvent pas — et quand je dis « ne peuvent pas », c’est réellement impossible — être détectées par l’application. En fait, lorsque l’attaque atteint l’application, il est déjà trop tard.

Bien sûr, je parle des attaques DDoS visant la couche applicative (HTTP). Vous savez, ces attaques vampiriques qui exploitent le protocole HTTP lui-même pour accaparer jusqu’à la dernière ressource de calcul et de mémoire disponible d’une application, afin de la rendre inutilisable par les utilisateurs légitimes.

Il existe essentiellement deux types d’attaques DDoS HTTP : les rapides et les lentes ; celles qui submergent et celles qui épuisent.

L’attaque par inondation

Une attaque DDoS HTTP par inondation exploite le fait que les applications sont censées accepter les requêtes HTTP et y répondre. C’est un peu leur raison d’être, non ? Elles s’exécutent donc, quelle que soit la vitesse à laquelle les requêtes affluent. Même si celles-ci arrivent à un rythme qui épuisera les ressources disponibles du serveur en quelques minutes, voire quelques secondes, celui-ci tente d’y répondre. En effet, chaque application (et, en réalité, chaque appareil, service, système, etc.) ne peut maintenir simultanément qu’un nombre limité de connexions TCP ouvertes, au-delà duquel elle ne peut tout simplement plus en ouvrir de nouvelles. Une fois cette limite atteinte, toutes les requêtes suivantes sont simplement ignorées. Pour les utilisateurs, cela se traduit par l’inoffensif message d’état « Tentative de connexion… », tandis que leur navigateur ou leur application attend l’expiration du délai défini par le système avant de leur annoncer qu’il est impossible de se connecter.

Ce type d’attaque peut survenir si rapidement (d’où l’analogie avec une « crue soudaine ») qu’il dépasse la capacité des systèmes à s’adapter à la demande. Même la mise à l’échelle automatique ne peut rien y faire, car le temps nécessaire pour provisionner et lancer une nouvelle instance de l’application est supérieur au temps qu’il faut à l’attaque pour épuiser toutes les ressources des instances existantes.

L’attaque par épuisement des ressources

À l’inverse, une attaque par épuisement accomplit la même tâche, mais en forçant l’application à maintenir une connexion ouverte plus longtemps que nécessaire. Pour ce faire, elle simule une connexion bas débit et ne récupère que quelques bribes de données par seconde auprès de l’application, au lieu de les recevoir au débit dont elle est réellement capable. Les connexions restent ainsi ouvertes plus longtemps et, si cette méthode est appliquée à un nombre suffisant de connexions, on aboutit pratiquement à la même situation qu’avec une attaque par inondation : l’épuisement des ressources.

Aucune de ces deux attaques ne peut être détectée depuis l’application. Et pour cause : du point de vue de l’application, toutes ces requêtes sont légitimes. Il s’agit de requêtes de données HTTP correctement formées, auxquelles elle répond probablement des milliers de fois par jour. Aucun indicateur dans les en-têtes HTTP ou la charge utile ne révèle la nature malveillante de ces requêtes. L’application est totalement aveugle aux intentions malveillantes qui les sous-tendent, car elle n’a aucune visibilité sur le réseau ni sur l’environnement au sens large, notamment sur la table des sessions du serveur, qui tient à jour la liste complète de toutes les connexions ouvertes. Je vous épargnerai les détails techniques et le cours sur les threads, les processus et la volatilité des données dans les environnements multithreads, et me contenterai de dire qu’elle « n’a aucune visibilité sur le traitement des autres requêtes ».

En somme, l’application elle-même n’a aucun moyen de déterminer si une requête donnée s’inscrit dans le cadre d’une attaque de plus grande ampleur (inondation) ou si son comportement est incompatible avec ses capacités connues (épuisement des ressources).

Le proxy à la rescousse

Ce qui a bel et bien une visibilité sur les deux, c’est le proxy situé en amont (devant) l’application. En effet, le proxy assure probablement la répartition de charge et doit donc surveiller à la fois le nombre de requêtes en cours de traitement et le nombre de requêtes entrantes, puisqu’il doit les acheminer vers l’une des applications du cluster (ou du pool, si vous préférez).

En outre, il doit savoir où envoyer la réponse. Il connaît donc le client et sa connexion réseau (seule l’adresse IP du client est généralement transmise à l’application, rien de plus). Contrairement à l’application, il dispose de la visibilité nécessaire pour détecter les attaques par inondation et par épuisement des ressources, et les arrêter avant qu’elles ne puissent planter leurs crocs de vampire dans les ressources de l’application.

C’est pourquoi les services basés sur un proxy, tels qu’un WAF (pare-feu d’application Web), voire un équilibreur de charge avancé, jouent un rôle essentiel dans les stratégies actuelles de sécurité des applications. Ils disposent en effet de la visibilité et des moyens nécessaires pour détecter les comportements anormaux révélateurs d’une attaque, et la repousser comme l’ail repousse les vampires.

Et puisque ces services traditionnellement « réseau » doivent nécessairement faire partie intégrante de l’architecture applicative, il semble logique qu’une approche DevOps élargisse son champ d’action et intègre davantage les services qui, par nature, sont étroitement liés à l’application, comme la sécurité applicative et l’évolutivité (répartition de charge).

Les applications ne peuvent pas arrêter toutes les attaques, en particulier celles dont la détection exige un niveau de visibilité auquel elles n’ont tout simplement pas accès. En revanche, en travaillant de concert avec des services étroitement liés aux applications, tels que la sécurité des applications web et l’équilibrage de charge, elles peuvent détecter et repousser un éventail plus large d’attaques, réduisant ainsi les interruptions de service et les failles de sécurité.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie