Lorsqu’il s’agit de failles impliquant des applications et une exposition de données, les développeurs sont presque toujours pointés du doigt. Bien souvent, c’est à juste titre. Les attaques par injection et les exploitations de la pile résultent presque toujours d’un code non sécurisé. Généralement parce que la règle de sécurité numéro zéro n’a pas été respectée.
Mais nous ne pouvons pas imputer toutes les failles de sécurité aux développeurs. En réalité, même si les développeurs pouvaient produire un code parfaitement sécurisé, des services applicatifs resteraient nécessaires pour se protéger contre de nombreuses autres attaques.
Cela s’explique par le fait que la sécurité des applications repose sur plusieurs couches. Certaines attaques exploitent des protocoles et des principes de mise en réseau auxquels il est impossible de remédier simplement en « sécurisant le code ». Pour compliquer encore la sécurité, ces attaques sont souvent indétectables par les applications, car celles-ci ne disposent pas d’une visibilité suffisante pour distinguer les requêtes malveillantes des requêtes légitimes.
En particulier, il existe trois types d’attaques que les développeurs ne devraient tout simplement pas avoir à gérer. Il est préférable que ces attaques soient détectées et atténuées par des services applicatifs déployés en amont, qui disposent de la visibilité et du contexte nécessaires pour y mettre fin.
DDoS volumétrique
Nous utilisons le terme « volumétrique » pour décrire une attaque traditionnelle par déni de service distribué, afin de distinguer les attaques fondées sur la saturation du réseau de celles qui ont remonté les couches de la pile pour cibler la couche applicative. Il s’agit de catégories d’attaques différentes, et nous devons donc être en mesure de nous défendre contre les unes comme contre les autres, mais les moyens d’y parvenir nécessitent des solutions très différentes.
Une attaque volumétrique est tout simplement une attaque massive. Un déluge de trafic est dirigé vers un service particulier dans le but de saturer le dispositif, l’infrastructure ou le logiciel chargé de traiter les requêtes. Le principe est que tous les systèmes — qu’ils soient matériels ou logiciels, sur site ou dans le cloud — disposent de ressources limitées. Ainsi, en envoyant suffisamment de requêtes, il est possible de saturer le système et de bloquer l’accès à tout ce qui se trouve derrière lui.
Si les développeurs ne peuvent pas empêcher efficacement cette attaque, c’est parce que les applications s’appuient sur les plateformes et les systèmes d’exploitation hôtes pour gérer le réseau. Une attaque DDoS volumétrique cible cette pile réseau et peut accaparer une telle quantité de ressources partagées que l’application parvient à peine à traiter les requêtes nécessaires pour déterminer qu’elle est attaquée.
La programmation sécurisée ne peut pas empêcher cela : il ne s’agit pas d’une exploitation rendue possible par une vulnérabilité. Et ce n’est réellement la faute du code d’aucune partie du système. C’est simplement que, même si nous nous efforçons de faire comme si le matériel n’existait pas, c’est bien de lui que proviennent les ressources, et celles-ci sont limitées.
Les attaques DDoS volumétriques sont mieux détectées et atténuées par des services applicatifs à haute capacité et hautes performances situés en amont d’une application. Plus ils sont proches de la source de l’attaque, mieux c’est.
Pas d’exploitation de faille, pas de solution de codage sécurisé.
DDoS de couche 7
En remontant la pile jusqu’à la couche applicative, on découvre une forme insidieuse de déni de service appelée attaque DDoS de couche 7 (ou HTTP). Ces attaques sont particulièrement exaspérantes, car elles exploitent le fonctionnement du système sans pour autant résulter d’une vulnérabilité ou d’un code non sécurisé. Elles tirent parti de la nature même du protocole HTTP et des systèmes qui le mettent en œuvre.
Il existe généralement deux types d’attaques DDoS de couche 7 : les lentes et les rapides. Une attaque DDoS lente de couche 7 consomme des ressources en simulant une très mauvaise connexion réseau et en récupérant t r è s l e n t e m e n t les réponses à des requêtes légitimes. Cela mobilise des ressources, car les applications web reposent sur des connexions et, là encore, les ressources permettant de maintenir ces connexions sont limitées. En connectant suffisamment de clients et en envoyant des requêtes légitimes dont les réponses ne sont reçues que très lentement, les attaquants parviennent à accaparer les ressources de l’application. Il devient alors presque impossible pour les clients légitimes de se connecter, ce qui revient à mener une attaque par déni de service.
Cette attaque est particulièrement pernicieuse et difficile à détecter, à moins de comparer les débits du réseau aux débits de réception. En effet, les services applicatifs en amont ont une visibilité sur les caractéristiques réseau des clients et peuvent déterminer plus précisément si ces derniers ralentissent délibérément la réception ou s’ils rencontrent réellement un problème de réseau. Il est essentiel de déterminer la légitimité des clients pour mettre fin à ce type d’attaque.
En résumé, ces attaques exploitent une vulnérabilité au niveau de la couche protocolaire (HTTP), et la programmation sécurisée ne peut rien faire pour y remédier.
Pas de vulnérabilité, pas de solution par le codage sécurisé.
Bourrage d’identifiants
Enfin, et ce n’est pas le moins important, il y a le credential stuffing. Le nombre incroyable d’identifiants exposés lors de violations de données ces dernières années fait de cette attaque une menace majeure contre laquelle il est essentiel de se protéger.
Les attaques par bourrage d’identifiants reposent généralement sur des bots ou des outils, car elles s’appuient sur des principes de force brute qui tirent parti des vastes ensembles de listes d’identifiants et de mots de passe existantes. Il est rare que ces attaques soient menées manuellement. La réussite d’une attaque par bourrage d’identifiants n’est pas due à un code non sécurisé*. Les attaquants cherchent uniquement à exploiter de mauvaises pratiques en matière de mots de passe et l’incapacité à détecter une attaque en cours.
Pour détecter ces attaques, vous devez être en mesure de déterminer que le client n’est pas un véritable être humain. Ainsi, dans une sorte de test de Turing inversé, vous devrez lui soumettre des épreuves et utiliser des CAPTCHA auxquels ces systèmes automatisés ne sont pas capables de répondre.
Aucune pratique de codage sécurisé ne peut empêcher cette attaque de réussir. L’amélioration des pratiques en matière de mots de passe et la détection des tentatives d’attaque sont les meilleurs moyens d’éviter de succomber à ce fléau grandissant sur Internet.
Pas de code exploitable, pas de solution de codage sécurisé.
*Les attaques par bourrage d’identifiants peuvent être rendues possibles par des pratiques de codage non sécurisées. En effet, un nombre important de violations de données sont dues à des vulnérabilités dans le code, qui entraînent la mise à disposition de listes massives d’identifiants pouvant être utilisées pour ce type d’attaque.
Différencier pour mieux détecter et se défendre
Il est important de savoir dans quels cas le développement sécurisé peut permettre de prévenir une attaque et dans quels cas il ne le peut pas. C’est essentiel, car nous ne pouvons pas continuer à rejeter la faute sur les développeurs à chaque attaque réussie. La sécurité exige une réflexion à l’échelle du système ; nous avons besoin de plusieurs solutions, car nous devons nous défendre contre différents types d’attaques.
Il est important de faire la distinction afin de se défendre efficacement contre les différents types d’attaques auxquels la plupart des organisations seront confrontées dans un avenir proche. Ne perdez pas de temps à vouloir contraindre les développeurs à se prémunir contre des attaques lorsque (1) celles-ci n’exploitent pas une faille due à un code non sécurisé ou (2) qu’il est impossible de s’en protéger en raison d’un manque de visibilité.
Nous devons aborder la sécurité de manière stratégique en nous appuyant sur un ensemble de services qui assurent une protection adaptée aux endroits appropriés, quelles que soient la source ou la surface d’attaque.
Restez en sécurité.
À propos de l’auteur
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 VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.