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 n'est qu'un blitz. Un barrage de trafic est dirigé vers un service particulier dans le but de submerger tout appareil/infrastructure/logiciel qui gère les demandes. Le principe en jeu est que tous les appareils – qu’ils soient matériels ou logiciels, sur site ou dans le cloud – ont des ressources limitées. Ainsi, en envoyant suffisamment de requêtes, l'appareil peut être surchargé et bloquer l'accès à tout ce qui se trouve derrière lui.
La raison pour laquelle les développeurs ne peuvent pas empêcher efficacement cette attaque est que les applications s’appuient sur des plates-formes et des systèmes d’exploitation hôtes pour gérer le réseau. Une attaque DDoS volumétrique cible cette pile réseau et est capable de consommer une telle quantité de ressources partagées que l'application est à peine capable de traiter les requêtes afin de déterminer qu'elle est attaquée.
Le codage sécurisé ne peut pas empêcher cela : il ne s’agit pas d’un exploit dû à une vulnérabilité. Et ce n’est vraiment pas la faute du code dans aucune partie du système. C'est tout simplement le cas : peu importe à quel point nous essayons de prétendre qu'il n'y a pas de matériel, c'est de là que viennent les ressources et elles sont limitées.
Les attaques DDoS volumétriques sont mieux détectées et atténuées par des services d’application haute capacité et hautes performances résidant en amont d’une application. Plus on est proche de la source de l’attaque, mieux c’est.
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.
Il existe généralement deux types d’attaques DDoS de couche 7 : lentes et rapides. Les attaques DDoS lentes de couche 7 consomment des ressources en prétendant avoir une connexion réseau terrible et en siphonnant lentement les réponses des requêtes légitimes. Cela consomme des ressources car les applications Web sont basées sur la connexion et, une fois de plus, les ressources nécessaires pour maintenir ces connexions sont limitées. En se connectant à suffisamment de clients et en effectuant des demandes légitimes uniquement pour recevoir lentement des réponses, les attaquants sont en mesure de bloquer les ressources de l'application. Cela a pour effet de rendre presque impossible la connexion des clients légitimes, ce qui revient à réaliser une 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 aborder la sécurité de manière stratégique à partir d’un système de services qui fournissent la bonne sécurité aux bons endroits, quelle que soit la source ou la surface d’attaque.
Soyez prudent.