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

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Dans notre prochain rapport « State of Application Delivery 2018 », nous constatons que l’utilisation des pare-feu d’applications web (WAF) augmente régulièrement depuis des années. C’est une bonne chose, car les applications constituent aujourd’hui la porte d’accès aux données des clients et des entreprises, et les méthodes traditionnelles de contrôle des accès au niveau de la couche réseau ne suffisent plus. En effet, les acteurs malveillants ciblent de plus en plus les identités et les applications elles-mêmes afin d’exploiter cet or numérique.

Alors, concrètement, comment un pare-feu applicatif web (WAF) atténue-t-il toutes ces vulnérabilités qui ne cessent de surgir comme de la mauvaise herbe dans un jardin ? Un WAF utilise trois méthodes principales pour détecter et prévenir les attaques web : refuser ou autoriser les requêtes, les inspecter et les rejeter, et utiliser des signatures.

Examinons-les une par une, voulez-vous ?

Refuser/Autoriser les requêtes

La méthode de refus/d’autorisation des requêtes ressemble beaucoup au modèle traditionnel de contrôle d’accès utilisé par les pare-feu réseau. Les requêtes sont refusées ou autorisées en fonction des informations disponibles. Ces informations peuvent être simples, comme une adresse IP, ou plus complexes et propres au protocole HTTP, comme OPTIONS ou METHODS.

• Listes de blocage/d’autorisation
  Si vous savez qu’un acteur malveillant utilise une adresse IP ou une plage d’adresses IP spécifique, bloquez-le. Si vous savez qu’une application n’est autorisée à recevoir des requêtes que depuis une adresse IP ou une plage d’adresses IP spécifique, n’autorisez que celles-ci. Il s’agit de la méthode de protection la plus simple, qui repose sur un ensemble d’informations relativement statique : les adresses ou plages d’adresses IP dont les requêtes doivent ou ne doivent pas provenir.
  
  Vous vous demandez peut-être pourquoi ne pas simplement utiliser un pare-feu réseau pour cela ? Après tout, c’est précisément son rôle. Sur site, cela fonctionne très bien. Mais si vous devez protéger des applications dans le cloud public, ce n’est pas toujours possible. Et si vous faites partie des 59 % de répondants à notre enquête State of Application Delivery 2018 qui utilisent déjà entre 2 et 6 fournisseurs de cloud différents, vous ne pouvez pas compter sur des politiques de pare-feu réseau identiques chez tous les fournisseurs. Vous pouvez bien sûr mettre en œuvre les mêmes règles dans plusieurs clouds, mais leur application au niveau d’un WAF vous permet d’utiliser la même politique avec le même WAF dans plusieurs environnements. La cohérence est essentielle pour garantir l’efficacité et l’évolutivité de la sécurité.
• Restriction des options
  HTTP s’appuie sur un ensemble d’en-têtes pour indiquer à la plateforme applicative (et à l’application) ce que l’utilisateur souhaite faire. Les MÉTHODES HTTP, par exemple, permettent d’utiliser GET, PUT, POST et DELETE sur des ressources. Le champ OPTIONS dispose lui aussi d’un ensemble de valeurs défini par une RFC, qui peut être facilement contrôlé par un WAF. Certaines vulnérabilités, comme Optionsbleed, exploitent ces champs. Pour empêcher l’exploitation de telles vulnérabilités, vous pouvez utiliser le WAF afin de limiter les valeurs possibles à celles qui sont strictement nécessaires au bon fonctionnement de l’application. Dans certains cas, le WAF limite ces valeurs par défaut. Par exemple, BIG-IP ASM (WAF de F5) n’autorise par défaut aucune utilisation de la méthode HTTP OPTIONS.

Signatures

Les signatures constituent une autre méthode de protection couramment utilisée par de nombreuses solutions de sécurité. Les services antivirus et antimalware s’appuient sur des signatures qui leur permettent de rechercher rapidement des traces de virus et de logiciels malveillants et de les signaler. Les systèmes IPS/IDS reposent eux aussi largement sur cette méthode, tout comme les WAF. Il existe deux types de signatures : celles définies par l’utilisateur et celles gérées par le fournisseur.

• Gérées par le fournisseur
  Les signatures gérées par le fournisseur sont généralement conservées dans une « base de données » automatiquement tenue à jour par celui-ci. Cela comprend 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 compare chaque requête entrante à la base de données et agit en conséquence s’il y trouve une signature correspondante. Les signatures peuvent être de simples chaînes de texte brut, mais il s’agit le plus souvent de combinaisons complexes de chaînes obscures représentant du code malveillant qui déclenche des fonctionnalités d’exécution à distance, compromet la plateforme applicative et permet d’y accéder, ou provoque un déni de service.
• Définies 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 fonctionnalité est essentielle pour réagir rapidement (dans de nombreux cas, dès le jour zéro) aux nouvelles vulnérabilités, ainsi que pour atténuer celles pour lesquelles aucune signature gérée par le fournisseur n’a encore été publiée.

Inspection

Enfin, l’inspection permet de garantir un contrôle total des requêtes (et des réponses). L’inspection des requêtes permet au WAF de comparer les informations qu’elles contiennent à des chaînes et valeurs connues comme étant fiables ou malveillantes, afin de déterminer si la requête est légitime ou non. Pour les applications HTTP (c’est-à-dire la plupart des applications présentes aujourd’hui sur Internet), il s’agit de la fonctionnalité la plus importante qu’un WAF doit offrir. Si un WAF ne propose pas d’inspection programmable, mieux vaut reconsidérer ce choix. HTTP étant un protocole textuel et extensible, il est pratiquement impossible de fournir une liste exhaustive d’options et de méthodes à cocher pour inspecter les requêtes. Très peu d’en-têtes HTTP imposent des restrictions sur les valeurs autorisées, ce qui rend très difficile de limiter les données qui peuvent y être insérées. L’inspection est donc souvent nécessaire pour détecter le code malveillant dissimulé dans les en-têtes ou dans la charge utile elle-même. L’inspection peut porter sur deux éléments : les en-têtes connus et la charge utile.

• En-têtes connus
  Il existe un ensemble d’en-têtes bien définis qui accompagnent chaque requête HTTP. Host, User-Agent, Content-Type, etc. sont presque omniprésents. Chacun n’est guère plus qu’une chaîne de texte, avec une telle variété de combinaisons qu’il est difficile d’établir une liste de valeurs autorisées ; il faut donc analyser chaque valeur individuellement afin de détecter celles qui semblent malveillantes. En règle générale, un WAF peut analyser très rapidement les en-têtes HTTP et permettre leur inspection. Ils se trouvent au début de chaque requête et sont connus pour avoir été utilisés afin de mener diverses attaques contre des plateformes applicatives : ApacheKiller, Optionsbleed et Apache Struts figurent parmi les vulnérabilités les plus connues.
• Inspection de la charge utile
  L’inspection de la charge utile consiste, comme son nom l’indique, à examiner l’intégralité de celle-ci, du premier au dernier octet, afin de détecter les combinaisons connues de données alphanumériques signalant une tentative d’exploitation d’une vulnérabilité. Elle permet aux opérateurs d’analyser les en-têtes HTTP personnalisés ainsi que le corps d’une requête à la recherche d’indicateurs précis d’activité malveillante. Pour cela, le WAF doit d’abord conserver l’intégralité du contenu de la requête. Cette étape est nécessaire, car les paquets ne peuvent contenir qu’une quantité limitée de données. Si les données malveillantes sont réparties sur deux paquets, elles peuvent échapper aux services qui se contentent d’examiner chaque paquet séparément. En inspectant l’intégralité de la charge utile, un WAF garantit que les données malveillantes seront détectées, où qu’elles se trouvent, et qu’elles ne pourront pas atteindre leur cible.

Un WAF peut faire bien plus que limiter les vulnérabilités afin de protéger les applications. Nombre d’entre eux intègrent également la détection des bots, la limitation du débit, la prévention des attaques DDoS, et bien plus encore. Mais la fonction première d’un WAF reste de protéger les applications en limitant les vulnérabilités. Bien que les injections SQL (SQLi), les attaques XSS et les attaques CSRF soient généralement citées, elles sont désormais presque dépassées. Les acteurs malveillants ne se contentent plus d’exploiter les vulnérabilités évidentes des applications et ont commencé à cibler les plateformes car elles leur offrent un vivier de victimes potentielles bien plus vaste. Les vulnérabilités des plateformes, c’est-à-dire celles qui touchent HTTP et ses frameworks, sont une source croissante de compromissions contre lesquelles les protections fournies par un WAF de classe entreprise sont efficaces.

En combinant les méthodes traditionnelles de refus/autorisation et les analyses basées sur des signatures avec la capacité d’inspecter l’intégralité d’une requête (et de sa réponse), un WAF offre aux entreprises la protection dont elles ont aujourd’hui besoin pour assurer leur sécurité et celle de leurs clients.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

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 Vittie