Trois attaques que vous ne pouvez pas arrêter avec un codage sécurisé

Lorsqu’il s’agit de violations impliquant des applications et l’exposition de données, les doigts sont presque toujours pointés vers les développeurs. Souvent, c’est la bonne direction. Les attaques par injection et les exploits basés sur la pile sont presque toujours le résultat d’un code non sécurisé. Habituellement parce que la règle de sécurité zéro a été violée.

Mais nous ne pouvons pas imputer toutes les violations aux développeurs. La vérité est que même si les développeurs pouvaient produire du code parfaitement sécurisé, vous auriez toujours besoin de services d’application pour vous protéger contre de nombreuses autres attaques.

C’est parce que la sécurité des applications est une pile . Il existe des attaques qui exploitent des protocoles et des principes de réseau qui ne peuvent pas être simplement « codés de manière sécurisée ». La sécurité est encore compliquée par le fait que ces attaques sont souvent indétectables par les applications car elles n’ont pas la visibilité nécessaire pour distinguer les requêtes malveillantes des requêtes légitimes.

Il existe notamment trois attaques dont les développeurs ne devraient tout simplement pas être responsables. Au lieu de cela, ces attaques sont mieux détectées et atténuées par les services d’application déployés en amont, où la visibilité et le contexte sont disponibles pour aider à les arrêter.

DDoS volumétrique

Nous utilisons le terme volumétrique pour décrire une attaque par déni de service distribuée traditionnelle afin de distinguer les attaques basées sur la surcharge du réseau de celles qui ont remonté la pile pour attaquer la couche application. Il s’agit de classes d’attaques différentes et nous devons donc être capables de nous défendre contre les deux, mais la manière dont nous le faisons nécessite des solutions très différentes.

Une attaque volumétrique est une forme de blitz. Vous subissez un flot massif de trafic ciblant un service précis dans le but d’épuiser l’appareil, l’infrastructure ou le logiciel qui traite les requêtes. Le principe est que tous les équipements — matériels ou logiciels, sur site ou dans le cloud — disposent de ressources limitées. En envoyant suffisamment de requêtes, vous risquez de saturer ce dispositif et de couper l’accès à tout ce qui dépend de lui.

Les développeurs ne peuvent pas empêcher efficacement cette attaque, car les applications dépendent des plateformes et des systèmes d'exploitation hôtes pour gérer le réseau. Une attaque DDoS volumétrique vise cette pile réseau et consomme tellement de ressources partagées que l'application n'arrive presque plus à traiter les requêtes, ce qui complique la détection de l'attaque.

Le codage sécurisé ne peut pas empêcher cela : il ne s'agit pas d'une exploitation liée à une vulnérabilité. Ce n'est pas non plus la responsabilité du code dans aucune partie du système. Peu importe nos efforts pour ignorer l’existence du matériel, ce sont les ressources qui en dépendent, et elles restent limitées.

Nous détectons et atténuons au mieux les attaques DDoS volumétriques grâce à des services applicatifs haute capacité et haute performance installés en amont de votre application. Plus nous intervenons près de la source de l'attaque, plus la protection est efficace.

Aucun exploit, aucune solution de codage sécurisée.

DDoS de couche 7

En remontant la pile jusqu'à la couche application, nous trouvons une forme insidieuse de déni de service appelée DDoS de couche 7 (ou HTTP). Ces attaques sont exaspérantes car elles sont des exploits, mais elles ne sont pas dues à une vulnérabilité ou à un codage non sécurisé. Ces attaques fonctionnent en raison de la nature du protocole HTTP et des systèmes qui le mettent en œuvre.

On distingue généralement deux types d’attaques DDoS de couche 7 : lentes et rapides. Les attaques lentes de couche 7 épuisent les ressources en simulant une mauvaise connexion réseau et en détournant progressivement les réponses des requêtes légitimes. Vous consommez ainsi des ressources car les applications web reposent sur des connexions, et les ressources pour les maintenir restent limitées. En établissant suffisamment de connexions clients et en émettant des requêtes valides tout en recevant lentement les réponses, les attaquants accaparent les ressources applicatives. Le résultat : les clients légitimes peuvent difficilement se connecter, provoquant une vraie attaque par déni de service.

Cette attaque est particulièrement néfaste et difficile à détecter, à moins que vous ne compariez les vitesses du réseau aux vitesses de réception. Autrement dit, les services d'application en amont ont une visibilité sur les caractéristiques réseau des clients et peuvent déterminer plus précisément si ces clients tardent volontairement à recevoir ou s'ils ont réellement un problème de réseau.  Déterminer la légitimité est essentiel pour mettre fin à ce type d’attaque.

Fondamentalement, ces attaques exploitent la couche de protocole (HTTP) et le codage sécurisé ne peut rien faire pour y remédier.

Aucune vulnérabilité, aucune solution de codage sécurisée.

Bourrage d’identifiants

Enfin et surtout, il y a le bourrage d’identifiants . Le nombre incroyable d'identifiants exposés suite à des violations au cours des dernières années fait de cette attaque un enjeu important contre lequel il faut se défendre.

Les attaques de bourrage d'informations d'identification s'appuient généralement sur des robots ou des outils, car elles reposent sur des principes de force brute qui exploitent les vastes pools de fichiers de noms d'utilisateur/mots de passe existants. Il est rare de trouver des attaques de vol d’identifiants effectuées manuellement. Une attaque de bourrage d’informations d’identification réussie n’est pas le résultat d’un codage non sécurisé*.  Les attaquants ne tentent pas d’exploiter quoi que ce soit d’autre que de mauvaises pratiques en matière de mots de passe et l’incapacité à reconnaître une attaque en cours.

Pour détecter ces attaques, vous devez être en mesure de déterminer que le client n’est pas un être humain valide. Ainsi, dans une sorte de test de Turing inversé, vous devrez présenter des défis et utiliser des CAPTCHA d'une manière que ces systèmes automatisés ne sont pas en mesure de répondre.

Aucun codage sécurisé ne peut empêcher cette attaque de réussir. Améliorer les pratiques en matière de mots de passe et détecter les tentatives d’attaques sont les meilleurs moyens d’éviter de succomber à ce fléau croissant d’Internet.

Pas de code exploitable, pas de solution de codage sécurisée.

*Les attaques de type « credential stuffing » peuvent être rendues possibles par un codage non sécurisé. Après tout, un nombre important de violations se produisent en raison de vulnérabilités basées sur le code qui donnent lieu à des listes massives d’informations d’identification disponibles pour cette attaque.

Différencier pour détecter et défendre

Il est important de reconnaître quand le codage sécurisé peut être utilisé pour empêcher une attaque et quand il ne le peut pas. C’est important parce que nous ne pouvons pas continuer à pointer du doigt les développeurs pour chaque attaque réussie. La sécurité nécessite une réflexion à l’échelle du système ; nous avons besoin de solutions multiples car il existe de nombreux types d’attaques contre lesquels nous devons nous défendre.

Il est important de faire la différence afin de se défendre efficacement et avec succès contre la variété d’attaques auxquelles la plupart des organisations seront soumises dans un avenir proche. Ne perdez pas de temps à essayer de forcer les développeurs à se défendre contre les attaques alors que ce n'est (1) pas un exploit en raison d'un codage non sécurisé ou (2) ce n'est pas possible en raison d'un manque de visibilité.

Nous devons adopter une approche stratégique de la sécurité en déployant un système de services qui garantit une protection ciblée, quelle que soit la source ou la surface d’attaque.

Soyez prudent.