Attaques de couche d'application - Bonnes pratiques AWS pour la résistance aux attaques DDoS

Attaques de couche d'application

Un attaquant peut cibler l'application elle-même en utilisant une attaque de couche 7 ou de couche application. Dans ces attaques, similaires aux attaques d'infrastructure SYN flood, l'attaquant tente de surcharger des fonctions spécifiques d'une application pour la rendre indisponible ou ne pas répondre aux utilisateurs légitimes. Cela peut parfois être réalisé avec de très faibles volumes de demandes qui ne génèrent qu'un faible volume de trafic réseau. Cela peut rendre l'attaque difficile à détecter et à atténuer. Parmi les exemples d'attaques de la couche application, citons les inondations HTTP, les attaques anti-cache et les inondations XML-RPC de WordPress.

Lors d'une attaque par inondation HTTP, un attaquant envoie des requêtes HTTP qui semblent provenir d'un utilisateur valide de l'application web. Certaines inondations HTTP ciblent une ressource spécifique, tandis que des inondations HTTP plus complexes tentent d'émuler l'interaction humaine avec l'application. Cela peut augmenter la difficulté d'utiliser des techniques d'atténuation courantes telles que la limitation du taux de demande.

Les attaques par destruction de cache sont un type d'inondation HTTP qui utilise des variations dans la chaîne de requête pour contourner la mise en cache du réseau de diffusion de contenu (CDN). Au lieu de pouvoir renvoyer des résultats mis en cache, le CDN doit contacter le serveur d'origine pour chaque demande de page, et ces récupérations d'origine entraînent une charge supplémentaire sur le serveur web de l'application.

Avec une attaque d'inondation WordPress XML-RPC, également connue sous le nom d'inondation de pingback WordPress, un attaquant cible un site web hébergé sur le logiciel de gestion de contenu WordPress. L'attaquant utilise à mauvais escient la fonction de l'API XML-RPC pour générer un flot de requêtes HTTP. La fonction pingback permet à un site web hébergé sur WordPress (site A) d'avertir un autre site WordPress (site B) via un lien que le site A a créé vers le site B. Le site B tente ensuite de récupérer le site A pour vérifier l'existence du lien. Dans un flux de pingback, l'attaquant utilise cette capacité à mauvais escient pour amener le site B à attaquer le site A. Ce type d'attaque a une signature claire : WordPress est généralement présent dans l'agent utilisateur de l'en-tête de la requête HTTP.

Il existe d'autres formes de trafic malveillant qui peuvent avoir un impact sur la disponibilité d'une application. Les robots Scraper automatisent les tentatives d'accès à une application web pour voler du contenu ou enregistrer des informations concurrentielles, telles que les prix. Les attaques par force brute et par « credential stuffing » sont des efforts programmés visant à obtenir un accès non autorisé aux zones sécurisées d'une application. Il ne s'agit pas uniquement d'attaques DDoS ; mais leur nature automatisée peut ressembler à une attaque DDoS et elles peuvent être atténuées en mettant en œuvre certaines des bonnes pratiques abordées dans ce document.

Les attaques de la couche application peuvent également cibler les services DNS (Domain Name System). La plus courante de ces attaques est une inondation de requêtes DNS au cours de laquelle un attaquant utilise de nombreuses requêtes DNS bien formées pour épuiser les ressources d'un serveur DNS. Ces attaques peuvent également inclure un composant briseur de cache dans lequel l'attaquant randomise la chaîne de sous-domaine pour contourner le cache DNS local d'un résolveur donné. Par conséquent, le résolveur ne peut pas tirer parti des requêtes de domaine mises en cache et doit contacter à plusieurs reprises le serveur DNS faisant autorité, ce qui amplifie l'attaque.

Si une application web est mise à disposition via le protocole TLS (Transport Layer Security), un attaquant peut également choisir d'attaquer le processus de négociation TLS. Le protocole TLS coûte cher en termes de calcul, de sorte qu'un attaquant, en générant une charge de travail supplémentaire sur le serveur pour traiter des données illisibles (ou inintelligibles (texte chiffré)) en tant que liaison légitime, peut réduire la disponibilité du serveur. Dans une variante de cette attaque, un attaquant termine l'établissement de liaison TLS, mais renégocie perpétuellement la méthode de chiffrement. Un attaquant peut également tenter d'épuiser les ressources du serveur en ouvrant et en fermant de nombreuses sessions TLS.