Comment un WAF atténue-t-il les vulnérabilités ?

Dans notre prochain rapport sur l’état de la distribution des applications 2018, nous constatons que l’utilisation de pare-feu d’applications Web (WAF) augmente régulièrement depuis des années. C’est une bonne chose, car les applications sont aujourd’hui la passerelle vers les données des clients et des entreprises et les méthodes traditionnelles de contrôle d’accès au niveau du réseau ne suffisent pas. C’est parce que de plus en plus d’acteurs malveillants ciblent les identités et les applications elles-mêmes pour extraire cet or numérique.

Alors, comment, exactement, un WAF atténue-t-il toutes ces vulnérabilités qui continuent à surgir comme des mauvaises herbes dans le jardin ? Il existe trois méthodes principales utilisées par un WAF pour détecter et prévenir les attaques Web : refuser/autoriser les demandes, inspecter et rejeter, et les signatures.

Explorons chacun d’eux, d’accord ?

Refuser/Autoriser les demandes

La méthode de refus/autorisation des demandes ressemble beaucoup au modèle de porte traditionnel utilisé par les pare-feu réseau. Les demandes sont refusées ou autorisées en fonction des informations disponibles. Ces informations peuvent être simples, comme une adresse IP, ou plus complexes et spécifiques à HTTP, comme des OPTIONS ou des MÉTHODES.

• Listes d'autorisation/de refus
  Si vous savez qu'un mauvais acteur provient d'une adresse IP spécifique ou d'une plage d'adresses IP, bloquez-le. Si vous savez qu'une application n'est autorisée à recevoir des requêtes que d'une adresse IP spécifique ou d'une plage d'adresses IP, autorisez-les uniquement. Il s’agit de la méthode de protection la plus simple, qui repose sur un ensemble d’informations assez statique : les adresses/plages IP d’où les requêtes doivent ou ne doivent pas provenir.
  
  Si vous vous demandez pourquoi ne pas simplement utiliser un pare-feu réseau pour faire cela ? Après tout, c'est ce qu'ils font. Sur site, cela fonctionne très bien. Mais si vous avez des applications que vous devez protéger dans le cloud public, cela n’est peut-être pas une option. Et si vous faites partie des 59 % de ceux qui, dans notre enquête sur l'état de la distribution des applications 2018, ont déjà investi dans 2 à 6 fournisseurs de cloud différents, vous ne pouvez pas compter sur le fait que les politiques de pare-feu réseau soient les mêmes chez tous les fournisseurs. Bien que vous puissiez certainement implémenter les mêmes règles dans plusieurs clouds, l’application de règles au niveau d’un WAF signifie que vous pouvez utiliser la même politique dans le même WAF dans plusieurs environnements. La cohérence est la clé du succès et de l’évolutivité de la sécurité.
• Options de restriction
  HTTP s'appuie sur un ensemble d'en-têtes pour indiquer à la plateforme d'application (et à l'application) ce que l'utilisateur souhaite faire. Les MÉTHODES HTTP, par exemple, peuvent être utilisées pour OBTENIR, METTRE, PUBLIER et SUPPRIMER des ressources. Le champ OPTIONS dispose également d'un ensemble de valeurs restreintes par RFC qui peuvent être facilement contrôlées par un WAF. Certaines vulnérabilités – comme Optionsbleed – exploitent ces champs. Pour éliminer la possibilité d’exploiter de telles vulnérabilités, vous pouvez utiliser le WAF pour restreindre les valeurs possibles à celles dont vous avez besoin pour permettre une exécution correcte de l’application. Dans certains cas, le WAF – par défaut – restreint ces valeurs. Par exemple, BIG-IP ASM (F5 WAF) par défaut n'autorise pas du tout la méthode HTTP OPTIONS.

Signatures

Les signatures sont une autre méthode de protection commune à de nombreuses solutions de sécurité différentes. Les services antivirus et anti-malware s'appuient sur des signatures qui leur permettent de rechercher rapidement des preuves de virus et de logiciels malveillants et de les signaler. Les IPS/IDS s’appuient également fortement sur cette méthode, tout comme le WAF. Il existe deux types de signatures : définies par l’utilisateur et gérées par le fournisseur.

• Géré par le fournisseur
  Les signatures gérées par le fournisseur sont généralement conservées dans une « base de données » automatiquement maintenue par le fournisseur. Cela inclut la mise à jour de la base de données lorsque de nouvelles vulnérabilités peuvent être identifiées par une signature numérique unique. Un WAF analysera une demande entrante dans la base de données et agira en conséquence s'il découvre une correspondance avec une signature dans la base de données. Les signatures peuvent être uniquement du texte brut, mais sont plus souvent des combinaisons complexes de chaînes obscures qui représentent du code malveillant qui déclenche des capacités d'exécution à distance ou corrompt la plate-forme d'application et fournit l'accès ou refuse le service.
• Défini par l'utilisateur
  Les signatures définies par l'utilisateur permettent aux opérateurs d'ajouter rapidement une signature à la base de données. Cette capacité est importante pour garantir une réponse rapide (zéro jour dans de nombreux cas) aux nouvelles vulnérabilités ainsi que pour atténuer les vulnérabilités pour lesquelles une signature gérée par le fournisseur n'a pas encore été émise.

Inspection

Enfin, une inspection est incluse pour assurer un contrôle complet sur les demandes (et les réponses). L'inspection des demandes permet au WAF de comparer les informations de la demande avec les chaînes et valeurs connues comme bonnes/mauvaises pour déterminer si la demande est malveillante ou légitime. Pour les applications HTTP (ce qui signifie la plupart d'entre elles sur Internet aujourd'hui), il s'agit de la capacité la plus importante qu'un WAF doit fournir. Si un WAF n’offre pas d’inspection programmable, vous devrez reconsidérer ce choix. Étant donné que HTTP est basé sur du texte et extensible, il n’existe pratiquement aucun moyen de fournir une liste complète de « cases à cocher » d’options et de méthodes que vous pouvez utiliser pour inspecter les requêtes. Très peu d'en-têtes HTTP ont des options restreintes, ce qui rend très difficile de limiter ce qui peut et ne peut pas y être inséré. Cela signifie qu’une inspection est souvent nécessaire afin de détecter le code malveillant intégré dans les en-têtes ou dans la charge utile elle-même. Il existe deux façons d'utiliser l'inspection : les en-têtes connus et la charge utile.

• En-têtes connus
  Il existe un ensemble d'en-têtes bien définis que chaque requête HTTP comporte. L’hôte, l’agent utilisateur, le type de contenu, etc… sont presque omniprésents. Chacun d'entre eux n'est guère plus qu'une chaîne de texte, avec une telle variété de combinaisons qu'il est difficile de mettre les valeurs sur liste blanche et qu'il faut plutôt les analyser individuellement pour détecter les valeurs d'apparence malveillante. D'une manière générale, un WAF peut très rapidement analyser les en-têtes HTTP et permettre leur inspection. Ils se trouvent au début de chaque requête et sont connus pour être utilisés pour commettre diverses attaques contre les plateformes d'applications : ApacheKiller , Optionsbleed et Apache Struts parmi les vulnérabilités les plus connues.
• Inspection de la charge utile
  L'inspection de la charge utile est ce que son nom indique : elle inspecte l'intégralité de la charge utile, du premier octet au dernier, à la recherche de combinaisons connues de données alphanumériques indiquant une tentative d'exploitation d'une vulnérabilité. L'inspection de la charge utile permet aux opérateurs d'examiner les en-têtes HTTP personnalisés ainsi que le corps d'une requête pour détecter des indicateurs spécifiques d'activité malveillante. Cela nécessite que le WAF détienne d’abord l’intégralité du contenu de la demande. Cela est nécessaire car les paquets ne contiennent qu'une quantité limitée de données, et si les données malveillantes s'étendent sur deux paquets, elles peuvent passer inaperçues pour les services qui inspectent simplement paquet par paquet. En inspectant l'intégralité de la charge utile, un WAF garantit que, quel que soit l'endroit où se trouvent les données malveillantes, elles peuvent être détectées et empêchées d'atteindre leur cible.

Un WAF peut faire bien plus que simplement atténuer les vulnérabilités pour protéger les applications. Beaucoup incluent également la détection de robots, la limitation du débit, la prévention DDoS, et bien plus encore. Mais l’objectif principal d’un WAF est de protéger les applications en atténuant les vulnérabilités. Bien que SQLi, XSS et CSRF soient généralement mentionnés, ceux-ci sont presque devenus « obsolètes » à ce stade. Les mauvais acteurs sont allés au-delà des vulnérabilités évidentes des applications et ont commencé à cibler les plateformes, car elles offrent un bassin de victimes beaucoup plus vaste dans lequel exploiter. Les vulnérabilités des plateformes (celles de HTTP et de ses frameworks) sont une source croissante de violations qui bénéficient des protections fournies par un WAF de classe entreprise.

En utilisant des analyses traditionnelles de refus/autorisation et basées sur les signatures avec la possibilité d'inspecter une demande complète (et une réponse), un WAF fournit la protection dont l'entreprise a besoin aujourd'hui pour assurer sa sécurité et celle de ses clients.