Comprendre l'attaque HTTP/2 CONTINUATION Flood

Comprendre l’attaque HTTP/2 CONTINUATION Flood

Bon cela fait un moment que cet article sur l’attaque HTTP/2 CONTINUATION Flood est dans mes brouillons, je vous préviens il y a pas mal de lecture ! Dites moi en commentaire si ce format vous plait et si vous voulez l’explication sur d’autres attaques ?

Bon, avant de comprendre ce qu’est une attaque HTTP/2 CONTINUATION Flood, il faut déjà comprendre le fonctionnement de ce protocole. Le protocole HTTP/2, une évolution du précédent HTTP/1.1 (qui aurait pu s’en douter 😉), est une avancée significative dans la manière dont les informations sont échangées sur le Web. Et oui, quand on surf sur la toile comme ici sur mon blog et bien il faut bien que nos ordinateurs se comprennent. HTTP/1.1 était pendant très longtemps le standard de la communication Web (depuis plus d’une décennie), mais à mesure que le trafic Internet augmentait, il avait du mal à répondre aux demandes de transfert de données plus rapides et plus efficaces. HTTP/2 a donc pour objectif de résoudre les limitations de HTTP/1.1 en introduisant plusieurs fonctionnalités clés qui ont rendu le protocole plus performant et plus robuste, tel que le multiplexage et la compression d’en-tête.

HTTP/2 permet de traiter plusieurs requêtes et réponses simultanément sur une seule connexion TCP, réduisant ainsi la latence et améliorant l’expérience utilisateur. Pour ce faire, il utilise un mécanisme de trame qui permet une meilleure utilisation de la bande passante disponible et une surcharge minimisée. Voici les principales caractéristiques apportées par HTTP/2 :

  • Multiplexage : au lieu du modèle « une requête par connexion », HTTP/2 prend en charge plusieurs flux simultanément sur une seule connexion, réduisant ainsi la surcharge liée à l’établissement de nombreuses connexions.
  • Compression d’en-tête : HTTP/2 réduit la redondance des en-têtes grâce à la compression HPACK, optimisant ainsi l’utilisation de la bande passante lors des échanges.
  • Priorisation : HTTP/2 permet de prioriser les requêtes afin que les ressources critiques se chargent plus rapidement, améliorant ainsi les performances des pages et la satisfaction des utilisateurs.
  • Cadrage binaire : contrairement à la transmission textuelle de HTTP/1.1, HTTP/2 utilise le cadrage binaire, ce qui rend l’analyse plus efficace pour les machines.

Bref, HTTP/2 est une avancée indispensable qui peut réduire le temps de chargement des pages Web de 50% à 80% par rapport à son prédécesseur et tout ça en réduisant la consommation de ressources du serveur, telles que la mémoire et la puissance de calcul.

Comment fonctionne HTTP/2

Pour bien comprendre l’attaque, commençons par comprendre le fonctionnement de HTTP/2. La communication HTTP/2 s’articule autour des trames, qui sont les plus petites unités de communication. Les trames peuvent faire partie de flux et une seule connexion peut avoir plusieurs flux. Une amélioration notable de HTTP/2 est son utilisation des ID de flux pour différencier les différentes conversations au sein d’une connexion. Cette utilisation efficace des trames et du multiplexage de flux constitue l’épine dorsale des améliorations des performances de HTTP/2. Les trames sont de différents types tels que les trames DATA, HEADERS et CONTINUATION. Chaque type de trame répond à un objectif spécifique en garantissant que les données circulent efficacement à travers une connexion. Par exemple, les trames DATA transportent des données utiles, tandis que les trames HEADERS contiennent des métadonnées nécessaires au traitement des demandes et des réponses. Les trames CONTINUATION entrent en jeu lorsqu’un seul ensemble d’en-têtes est trop grand pour tenir dans une seule trame HEADERS.

Rôle des trames CONTINUATION dans la communication HTTP/2

La trame CONTINUATION (qui nous intéresse ici vous l’aurez compris) est utilisée lorsque le bloc d’en-tête d’une requête ou d’une réponse est trop grand pour une seule trame HEADERS. En utilisant les trames CONTINUATION, HTTP/2 peut diviser les gros en-têtes sur plusieurs trames. Cette approche maintient le flux de données tout en permettant la gestion de plus grands ensembles de métadonnées. Malgré leur utilité, les trames CONTINUATION présentent des vulnérabilités. Lorsqu’un serveur traite plusieurs trames contenant un seul bloc d’en-tête, il est obligé de conserver l’intégralité du bloc en mémoire jusqu’à ce qu’il soit complètement réassemblé. Et c’est ce phénomène obligatoire qui ouvre les portes à une vulnérabilité.

HTTP/2 CONTINUATION Flood

Qu’est-ce qu’une attaque HTTP/2 CONTINUATION Flood ?

L’attaque CONTINUATION Flood exploite la fonctionnalité des trames CONTINUATION pour surcharger les serveurs HTTP/2. Dans cette attaque, l’attaquant envoie plusieurs trames CONTINUATION fragmentées sans les terminer, ce qui oblige le serveur cible à conserver indéfiniment des blocs d’en-tête incomplets en mémoire. Cela épuise finalement les ressources du serveur et en exploitant ce mécanisme, l’attaquant effectue effectivement une attaque par déni de service (DoS) où le trafic légitime est privé des ressources du serveur en raison d’une surcharge due à des requêtes incomplètes. Contrairement aux attaques « traditionnelles », qui inondent généralement le serveur de nombreuses requêtes complètes, l’attaque HTTP/2 CONTINUATION Flood cible la gestion interne des métadonnées par le protocole.

L’attaque HTTP/2 CONTINUATION Flood partage des similitudes avec les attaques DDoS de la couche application qui visent à épuiser les ressources en abusant des mécanismes de protocole de haut niveau. Cependant, contrairement aux attaques DDoS volumétriques qui surchargent la bande passante grâce aux données brutes, l’attaque HTTP/2 CONTINUATION Flood est plus subtile. Il utilise la complexité inhérente au traitement des en-têtes pour consommer la mémoire et le processeur du serveur.

Impact de l’inondation de CONTINUATION HTTP/2 sur les serveurs

L’un des principaux impacts d’une attaque HTTP/2 CONTINUATION Flood est la pression exercée sur la mémoire du serveur. Étant donné que les serveurs doivent maintenir leur état jusqu’à ce que l’intégralité du bloc d’en-têtes soit reçue, l’allocation des ressources augmente. La consommation de mémoire peut augmenter rapidement et, à mesure que l’attaque progresse, le trafic légitime est soit retardé, soit entièrement refusé, rendant le serveur incapable de traiter les requêtes réelles des utilisateurs. Ces attaques entraînent souvent des temps d’arrêt prolongés et une consommation massive de ressources, obligeant les entreprises à mettre temporairement leurs services hors ligne ou à rediriger le trafic vers des canaux moins efficaces.

La détection des attaques HTTP/2 CONTINUATION Flood est difficile, car les trames individuelles dans HTTP/2 n’indiquent pas immédiatement une intention malveillante. Les trames CONTINUATION sont des constructions légitimes au sein du protocole, et distinguer une attaque d’une véritable tentative d’envoi d’en-têtes volumineux nécessite une analyse sophistiquée du trafic et une évaluation contextuelle, ce qui n’est pas toujours simple. Mais alors comment atténuer les attaques ?

Stratégies d’atténuation pour l’attaque HTTP/2 CONTINUATION Flood

Il n’existe pas de solution miracle, mais malgré tout quelques solutions d’atténuations que vous pouvez mettre en place.

Défenses au niveau du réseau

D’un point de vue de votre, vous pouvez limiter le débit et les connexions, permettant d’atténuer les effets des attaques. En limitant le nombre de trames ou de connexions pouvant être envoyées à partir d’une adresse IP particulière, le serveur peut éviter d’être la proie d’allocations de mémoire répétées mais cela ne vous protégera pas d’une attaque utilisant un réseau de Botnet. Les pare-feu équipés de Deep Packet Inspection (DPI) peuvent également aider en analysant la nature du trafic à un niveau plus granulaire et détecter/bloquer une attaque. La mise en place d’un WAF (Web Application Firewall) est une bonne solution aussi et vous protègera en plus d’une bonne partie des attaques sur un serveur web. Utiliser des équilibreurs de charge peut aider à atténuer les attaques en répartissant la charge et donc la pression sur vos serveurs.

Solutions au niveau des applications

Comme toujours, mettez régulièrement à jour votre serveur web pour permettre de corriger les dernières vulnérabilités. Au niveau de l’application, la mise en œuvre de limites de taille de requête et l’utilisation de reverse proxys peuvent contribuer à alléger certaines charges sur le serveur. Les reverse proxys peuvent traiter les requêtes dans un premier temps, permettant uniquement au trafic légitime d’acheminer vers le serveur d’applications principal. Les correctifs spécifiques à HTTP/2 qui limitent le nombre de trames CONTINUATION ou imposent des délais d’attente plus stricts pour l’achèvement des en-têtes peuvent également réduire la vulnérabilité.

Outils et techniques de détection des attaques HTTP/2 CONTINUATION Flood

Pour détecter les attaques CONTINUATION Flood, vous pouvez mettre en place des outils dédiés qui vont surveiller spécifiquement les trames CONTINUATION incomplètes ou prolongées. Les analyseurs de trafic réseau et les systèmes de détection d’intrusion (IDS) capables d’analyser le trafic HTTP/2 peuvent aider à identifier un comportement inhabituel dans les modèles d’échange de trames.

La norme ASVS (Application Security Verification Standard) de l’OWASP comprend des directives spécialement conçues pour sécuriser les protocoles Web, notamment HTTP/2. Il recommande des audits de sécurité réguliers, le respect des versions logicielles à jour et la définition de limites de taille de trame appropriées pour éviter les abus.

HTTP/3 une alternative plus sûre ?

HTTP/3, qui fonctionne sur QUIC au lieu de TCP, introduit des fonctionnalités qui pourraient atténuer certaines des vulnérabilités observées dans HTTP/2. QUIC utilise UDP, permettant une gestion plus flexible des flux et des connexions, ce qui peut réduire le risque d’épuisement des ressources dû à des séquences de trames incomplètes. Cependant, comme tout protocole, HTTP/3 nécessitera également des tests robustes pour confirmer sa résistance à des formes d’abus similaires. Au moment où j’écris ces lignes et à ma connaissance, il n’y a pas de preuve de la robustesse de HTTP/3 sur une attaque CONTINUATION Flood, n’hésitez pas à commenter si vous avez de la documentation sur le sujet !

À mesure que les protocoles évoluent, les méthodes d’attaque évoluent également et souvent plus vite que prévu. Les attaquants s’adapteront probablement à HTTP/3 en trouvant de nouvelles façons d’exploiter ses fonctionnalités, telles que la réinitialisation du flux QUIC ou la manipulation au niveau des paquets. Et avec l’IA, il y a fort à parier que l’avenir des attaques HTTP soit prometteur. L’IA pourrait aussi servir à détecter ce genre d’attaque, qui sait ?

En bref, même si le protocole HTTP/2 a été conçu pour améliorer les performances Web, sa conception introduit également de nouvelles vulnérabilités. Une attaque HTTP/2 CONTINUATION Flood cible le protocole HTTP/2 en envoyant des trames CONTINUATION fragmentées sans les terminer, ce qui oblige le serveur à allouer de la mémoire jusqu’à ce qu’elle soit épuisée. Il est possible de limiter ces attaques en mettant en œuvre des limites de débit, en utilisant des équilibreurs de charge, en appliquant des délais d’attente stricts et en surveillant l’activité des trames pour détecter les blocs d’en-tête incomplets.

Si l’article vous a plu et si vous aimez mon travail, vous pouvez faire un don en suivant ce lien :

Faire un don : https://www.paypal.com/donate/?hosted_button_id=DJBF7C54L273C

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Retour en haut