Les attaques par déni de service distribué (DDoS) dans la couche application tentent de planter les serveurs Web en les inondant de demandes. Le filtrage et l’équilibrage du trafic peuvent protéger contre de nombreuses attaques de la couche application, mais l’élimination des vulnérabilités dans vos applications Web est tout aussi importante pour minimiser les risques.
Points clés à retenir:
- Les six principaux types d’attaques DDoS au niveau de la couche application utilisent différentes méthodes pour atteindre le même objectif : envoyer tellement de requêtes à un serveur Web qu’il cesse de répondre correctement.
- Une attaque DDoS réussie empêche le trafic légitime d’accéder à un site Web, laissant les utilisateurs frustrés et amenant les entreprises à perdre potentiellement des ventes.
- Les défenses périmétriques telles que les pare-feu et les outils de surveillance peuvent absorber l’impact des attaques DDoS, mais les équipes de développement doivent également éliminer les vulnérabilités qui pourraient être ciblées.
Les attaques par déni de service distribué (DDoS) au niveau de la couche application se présentent sous de nombreuses formes et les attaquants peuvent les exécuter pour de nombreuses raisons, mais elles ont un point commun : elles tirent parti du fonctionnement des applications Web pour envoyer beaucoup plus de requêtes que le Web. les serveurs peuvent gérer. Les organisations peuvent prendre de nombreuses mesures préventives, notamment des pare-feu d’applications Web et la surveillance du trafic Web. Mais ils ne doivent pas négliger le fait qu’ils peuvent également réduire leur exposition à de telles attaques en détectant, corrigeant et prévenant les vulnérabilités des applications Web, même lorsqu’une application est déjà en production.
Comprendre l’attaque DDoS de la couche application
Une attaque DDoS au niveau de la couche application cible la couche de données d’une application Web avec laquelle l’utilisateur final interagit. Dans une interaction légitime typique, un utilisateur individuel fait une seule demande au serveur Web d’une application. Lors d’une attaque DDoS au niveau de la couche application, le serveur est inondé de bien plus de requêtes qu’il ne peut en gérer, ou de requêtes malveillantes qui le ralentissent jusqu’à l’exploration dans le but de répondre. Cela rend l’application inaccessible – d’où un déni de service . Vous verrez également de telles attaques appelées attaques de couche 7 car l’application est la septième couche du modèle informatique OSI (Open Systems Interconnection), tel que défini pour la première fois par l’Organisation internationale de normalisation (ISO) en 1994.
Dans ces scénarios, les attaquants profitent du fait que faire une requête nécessite beaucoup moins de ressources informatiques que de répondre à une requête. Par exemple, alors qu’un utilisateur n’a qu’à saisir un terme dans le champ de recherche d’un site Web et à appuyer sur Entrée, le serveur Web doit interroger une base de données pour renvoyer les résultats de la recherche. Si suffisamment d’utilisateurs – ou de bots malveillants, qui représentent plus d’un quart du trafic Web – exécutent une requête, le serveur est débordé et l’application Web devient inaccessible.
Six des attaques DDoS les plus courantes au niveau de la couche application
Bien qu’il existe de nombreux types d’attaques DDoS dans la couche application, ces six exemples sont parmi les plus courants.
- Débit lent : envoi de requêtes HTTP ou TCP malveillantes qui semblent être du trafic légitime à un débit très lent. Un type d’outil d’attaque à vitesse lente, Slowloris, ouvre une connexion à un serveur mais ne termine jamais la connexion. Cela oblige le serveur à maintenir les connexions ouvertes au nombre maximum autorisé.
- Publication lente : Envoi d’un en-tête de publication HTTP légitime à une vitesse suffisamment lente pour empêcher les utilisateurs légitimes d’accéder à un serveur, mais pas suffisamment lente pour qu’une connexion expire.
- Lecture lente : Envoi d’une requête HTTP à un serveur mais lecture de la réponse si lente que les autres utilisateurs ne peuvent pas accéder au serveur – mais encore une fois, pas assez lent pour qu’un délai d’attente se produise.
- Inondation HTTP(S) : utilisation d’un réseau de botnets pour submerger un serveur avec des requêtes HTTP Get ou Post gourmandes en calculs qui, autrement, semblent être un trafic valide.
- Navigation utilisateur imitée : utilisation de botnets pour se faire passer pour des utilisateurs humains afin de submerger un serveur, de faire planter un site Web et de le rendre inaccessible aux utilisateurs légitimes.
- Poste de charge utile volumineux : Consomme la mémoire d’un serveur Web en envoyant de très grandes structures de données XML qui doivent être décodées.
Signes d’une attaque DDoS au niveau de la couche application en cours
Quel que soit le type d’attaque DDoS au niveau de la couche application, il y a souvent trois signes révélateurs qu’elle se produit :
- Il y a beaucoup de trafic provenant de clients ayant des caractéristiques similaires, qu’il s’agisse de types d’appareils mobiles, de versions de navigateur, d’adresses IP ou d’emplacements.
- Il y a une augmentation significative, inattendue et inexplicable du trafic sur un seul serveur.
- Les serveurs plantent sans raison apparente et/ou un site Web prend beaucoup plus de temps que d’habitude pour répondre aux demandes.
Il convient de noter que ces signes sont similaires à des incidents DoS non intentionnels – des situations dans lesquelles des pics soudains de trafic légitime bloquent les serveurs Web. En effet, les attaques DDoS ont tendance à être spécifiquement conçues pour imiter la navigation Web et l’utilisation légitimes du site Web. Certains profitent également de vulnérabilités facilement identifiables dans la façon dont les applications Web ont été développées.
Les motivations d’une attaque DDoS au niveau de la couche application
Comme pour la plupart des cyberattaques, ceux qui mènent une attaque au niveau de la couche application peuvent être motivés par quelques facteurs différents :
- Envoyez un message idéologique en fermant le site Web d’un individu ou d’une organisation à laquelle ils s’opposent. Ceci est parfois appelé hacktivisme .
- Fermez le site Web d’un rival commercial ou politique.
- Exiger une rançon d’une victime d’attaque en échange de l’arrêt d’une attaque.
- Gagnez le respect des autres pirates malveillants.
- Utilisez l’attaque comme une diversion pour effectuer une autre attaque pendant que le personnel informatique est autrement occupé.
- Entraver les capacités d’un État ou d’une organisation adverse dans le cadre de campagnes de cyberguerre.
Les risques d’une attaque DDoS au niveau de la couche application
L’un des plus grands risques d’une attaque réussie de la couche application est qu’elle peut fermer un site Web et les services qu’il fournit. Dans les heures qu’il faut pour atténuer une seule attaque, une entreprise peut ne pas être en mesure de prendre des commandes en ligne, ce qui frustre les clients existants et oblige les clients potentiels à aller ailleurs. Si un site Web de l’administration publique est supprimé, des services essentiels peuvent être refusés aux citoyens.
Cependant, la plupart des pirates malveillants ne s’arrêtent pas à une seule attaque. Les botnets peuvent être facilement programmés pour modifier leurs demandes à un serveur. De cette façon, si un opérateur de site Web identifie des modèles de trafic fictif et prend des mesures pour l’arrêter – en interdisant le trafic à partir d’une certaine adresse IP, par exemple – un attaquant peut adopter une autre tactique.
Les organisations qui tentent d’identifier et de répondre à ces modèles à l’aide de processus manuels risquent de se retrouver dépassées. Cela pourrait avoir des implications financières importantes pour toute entreprise qui compte sur son site Web pour générer des ventes, car un site Web qui est frappé par des attaques fréquentes et des pannes continues verra une diminution à long terme du trafic légitime.
Quelques étapes clés pour prévenir les attaques DDoS au niveau de la couche application
Étant donné que les bots sont souvent à l’origine de certaines des attaques les plus courantes de la couche application, un test CAPTCHA est une étape simple qui peut aider à empêcher les bots d’inonder un serveur Web de requêtes. Il est également possible de limiter le nombre de requêtes qu’un serveur peut recevoir ou auxquelles répondre sur une certaine période de temps. Cependant, CAPTCHA peut être contourné par l’apprentissage automatique ou la force brute, et les limites de demandes pourraient nuire à un site Web si le trafic légitime augmente lorsque, par exemple, le produit d’une entreprise reçoit un cri inattendu d’une célébrité sur les réseaux sociaux.
Les mesures préventives supplémentaires pour les attaques DDoS incluent :
- Un pare-feu d’application Web qui filtre et équilibre les demandes de serveur entrantes ainsi que les données sortantes.
- Des outils d’analyse de paquets qui peuvent rejeter les paquets potentiellement malveillants à mesure qu’ils arrivent.
- Bases de données de réputation IP qui filtrent le trafic entrant.
- Une combinaison d’analyse de flux et d’analyse de comportement pour déterminer à quoi ressemble le trafic « normal » et faciliter potentiellement la détection des anomalies.
Bonnes pratiques de protection : rechercher et éliminer les vulnérabilités des applications
Les mesures mentionnées ci-dessus peuvent être utiles en tant que défenses périmétriques et représentent un composant de la protection de la sécurité de la couche application. Cependant, il est courant d’utiliser des services externes tels que Cloudflare pour gérer cet aspect de la protection pour vous. Pour les éléments que vous pouvez contrôler, il est important de ne pas négliger l’application elle-même , car les attaquants peuvent également cibler certaines des fonctionnalités essentielles des applications Web modernes.
Un exemple est les en-têtes de sécurité HTTP , qui sont un sous-ensemble des en-têtes HTTP qui échangent des détails sur les communications HTTP. Si ces en-têtes ne sont pas configurés correctement, ils peuvent laisser une application Web vulnérable aux attaques de script intersite (XSS), de l’homme du milieu (MITM) ou de détournement de clic. Les cookies contenant des données sensibles en sont un autre exemple. Avec les mauvais attributs de sécurité en place, ou sans aucun attribut défini, les attaquants peuvent voler des cookies (dans les attaques XSS ou MITM) ou prendre le contrôle des cookies et les utiliser à des fins malveillantes.
Il peut être difficile d’identifier ces types de vulnérabilités au cours du développement, car elles ne se présentent pas tant qu’une application n’est pas en cours d’exécution. C’est là que les tests dynamiques de sécurité des applications (DAST) entrent en jeu. Les solutions DAST se comportent comme les utilisateurs ordinaires sur Internet pour identifier les vulnérabilités qui existent dans une application en production, informer les équipes de développement de l’impact des vulnérabilités et fournir des conseils de correction.
DAST peut assurer la sécurité du cycle de vie du développement logiciel, en analysant les applications selon un calendrier régulier et, en combinaison avec des protections au niveau du réseau et l’équilibrage de charge, en aidant à garantir que les applications sont beaucoup moins susceptibles d’être supprimées par un trafic malveillant.
