Sécurité : pourquoi le WAF est-il indispensable ?

Disponibles directement sur internet, utilisant de plus en plus du code partagé et traitant bien souvent des données sensibles (données bancaires, données clients…), les applications web sont devenues une cible privilégiée d’attaques pour les cybercriminels. Explications.

Les pirates se tournent ainsi de plus en plus vers des techniques d’infiltration visant la couche applicative au détriment des attaques réseau qui sont de plus en plus compliquées à mettre en place (au vu de la complexité des architectures et des protections périmétriques actuelles). Du coup, les applications web deviennent une cible privilégiée ; script kiddy aux campagnes plus organisées disposant de moyens techniques, économiques et organisationnels importants : tout le monde s’y met ! Dans la protection des applications web, le WAF est une brique indispensable : voici pourquoi.

Comment ça marche ?

Avant tout, il faut savoir plusieurs choses sur les Web Application Firewall :

• Il existe plusieurs types de solutions  et donc plusieurs types d’implémentations
  Premièrement, les solutions dites « Built-in », qui sont des modules du serveur WEB (OWASP ModSecurity) ou des Frameworks (php-ids) qui sont directement embarqués au sein du serveur lui-même. Ensuite, selon le positionnement, ils peuvent être placés en mode « Monitoring » / sonde ou en coupure. Dans le premier cas, ils adoptent le fonctionnement d’un IDS afin de détecter et d’émettre des alarmes en cas d’intrusion. Le mode en coupure est le plus utilisé, soit en mode transparent (Bridge) ou soit en rupture protocolaire (Reverse Proxy). Ce mode Reverse Proxy est souvent préféré aux autres en raison de ses multiples avantages : le suivi des sessions, l’authentification et l’autorisation, les fonctionnalités réseaux avancées et bien sur sa capacité de réécriture des URLs.
• Les WAFs fonctionnent suivant 2 modèles de sécurité. Tout d’abord le modèle négatif : il entraîne une action du WAF lors de la détection d’une attaques connue, typiquement par le biais d’une signature. Ensuite le modèle positif, c’est le modèle le plus efficace mais un vrai casse-tête à mettre en place. Ce modèle d’appuie sur le fonctionnement normal de l’application afin de construire sa politique de sécurité. Le Web Application Firewall ne laissera passer que les flux et comportement normaux de l’application et bloquera le reste.
• Comme expliqué précédemment dans le mode Reverse Proxy, un WAF peut également coupler plusieurs options afin d’améliorer les performances d’une application notamment grâce à la compression, le cache, l’accélération SSL, l’équilibrage de charge, et j’en passe
• Les solutions de Web Application Firewalls se sont développées en parallèle des applications cloud. Fréquemment couplés avec des solutions de protection contre les attaques en déni de service elles permettent de garantir la disponibilité des applications à protéger.

Et concrètement, comment ça me protège ?

Les solutions disponibles sur le marché sont nombreuses et leurs qualités de services sont spécifiques à chacune. Elles se basent cependant souvent sur les mêmes mécanismes de protection, je vais vous en citer quelques-uns.

Conformité protocolaire : le WAF s’assure de la bonne conformité protocolaire en contrôlant l’entête http, les champs de formulaire, l’URL, etc. En vérifiant par exemple la taille de certains champs, le pare-feu pourra alors bloquer des attaques par Buffer Overflow.

Protection contre les injections SQL : pour les attaques de type injection (SQL Injection, OS Command Injection, LDAP Injection, …), les WAFs se basent principalement sur des signatures d’attaques en utilisant du « pattern matching » afin d’identifier un comportement anormal. Les injections étant très souvent véhiculées par un POST http ou dans une URL, il est intéressant de soumettre ces données à un contrôle des caractères envoyés. En effet, les injections SQL nécessitent souvent l’emploi de caractères de type «= », « ” », «-»… une règle bloquant ces caractères dans les formulaires de saisie (ou dans certains paramètres) permet de se prémunir contre ces attaques.

Protection DDOS : une majorité de pare-feu applicatif propose des protections contre les attaques par déni de service applicatif. Cette protection est assez délicate à mettre en place mais elle se base sur 2 principaux piliers :

• un contrôle comportemental en analysant le nombre de requêtes par seconde (par utilisateur ou global),
• le temps de réponse des serveurs.

Lorsque les seuils sont atteints, des contre-mesures seront mises en place : Limitation du nombre de requêtes, blacklisting, etc.

Prévention du vol de session HTTP : pour se prémunir contre les vols de sessions HTTP, plusieurs mécanismes peuvent être mis en place. Notamment le chiffrement SSL qui permet d’éviter le vol de cookies par un sniffer. Ensuite le pare-feu peut également proposer un mécanisme de protection des cookies par signature ou par chiffrement. Ainsi via cette fonctionnalité, le pare-feu empêche à la fois la visualisation et la manipulation des cookies.

Enfin, la dernière protection utilise un mécanisme de détection des bots ou vers. Dans ce cas, les pare-feu applicatifs vont vérifier si la requête est émise par un browser légitime ou par un script de génération de requête.

Si vous souhaitez aller plus loin je vous recommande cet article consacré aux Best Pratices en matière de WAF.

Le WAF : c’est aussi une protection immédiate sans toucher au code

La prévention contre le risque d’attaques applicatives est bien entendu le principal facteur décisionnel pour l’implémentation d’un WAF mais il n’est pas le seul. Le cycle de développement typique d’une application oublie bien souvent de prendre en considération la sécurité dès le design. Encore trop peu de développeurs sont sensibilisés à la sécurité et il n’est pas rare qu’ils utilisent de nombreuses APIs ou des bouts de code trouvés sur le net sans en tester la robustesse.

L’idée est donc, grâce aux fonctionnalités de Virtual Patching, de corriger directement sur le WAF les vulnérabilités présentes sur l’application. Vous allez me demander pourquoi réaliser cette action sur le pare-feu applicatif au lieu de l’application ? Et bien tout simplement car la mise en place d’un patch au sein de l’application peut-être beaucoup plus long et complexe que la création d’une règle sur le WAF. En effet l’utilisation d’applications tierces (base de données etc) au sein de l’application fait que le développeur n’a pas toujours la maitrise de l’intégralité code. Autre facteur important, la conformité avec des standards et normes comme PCI DSS 6.6, qui exige de toute application utilisant le paiement en ligne par cartes de s’équiper d’un Web Application Firewall.

Pour conclure

De par la richesse de ses fonctions de sécurité il est vrai qu’un pare-feu applicatif peu se rendre très utile voire obligatoire dans certaines situations mais il ne faut pas pour autant en négliger l’aspect sécurité lors de l’élaboration d’une application, le fameux « Secure by design ».

Roland

Pour aller plus loin :

Sécurité : une approche globale de la sécurité

La nouvelle frontière : protéger les données où qu'elles se trouvent