Le placement du pare-feu applicatif web

Les pare-feu applicatifs qui sont des appliances sont d’habitude placés directement derrière un pare-feu classique et avant les serveurs Web de l’organisation. Habituellement le positionnement du pare-feu applicatif fait que tout le trafic web passe à travers celui-ci. Pourtant, certaines solutions peuvent être positionnées sur un port de surveillance du réseau (network monitoring port) et donc elles reçoivent une copie du trafic réseau.

Les pare-feu applicatifs qui sont intégrées directement dans les serveurs web fournissent des fonctionnalités similaires en traitant le trafic avant qu’il n’atteigne l’application web.

Le modèle de sécurité

Un pare-feu applicatif suit généralement soit un modèle de sécurité positive ou négative quand il s’agit de l’élaboration de politiques de sécurité pour les applications Web.

Le modèle de sécurité négatif autorise par défaut toutes les transactions. Seules les transactions contenant des attaques sont rejetées. Basé sur une signature, le pare-feu applicatif détecte les attaques en exécutant des correspondances de définitions. Et, comme c’est le cas avec les logiciels antivirus et les systèmes de prévention des intrusions (IPS), la vitesse, la qualité et la quantité de mises à jour des signatures publiées par le fournisseur sont cruciaux.

Pour ce qui est du modèle de sécurité positif, le pare-feu applicatif refusera toutes les transactions par défaut et s’appuiera sur les ensembles de règles pour autoriser les seules transactions réputées fiables. Cette méthode exigera du firewall une activité d’apprentissage non négligeable pour détecter les transactions légitimes. Pour le WAF fonctionnant de la sorte, il est important de savoir s’il prendra en charge les mises à jour automatiques pour son modèle de comportement applicatif, sans devoir le former à nouveau lors de chaque mise à jour. En outre, il convient de s’intéresser aux techniques de normalisation qu’il utilise afin que des pirates ne puissent pas esquiver votre firewall en modifiant tout simplement une charge utile malveillante afin qu’elle semble inoffensive.

Le modes de fonctionnement

Les pare-feu applicatifs web peuvent fonctionner dans plusieurs modes distincts.
Chaque mode offre divers avantages et inconvénients qui obligent les organisations à évaluer la place optimale du WAF dans l’infrastructure réseau.

Le mode passif

Dans le mode passif, le WAF écoute le trafic sur un port de control (n’est pas en ligne directe avec le trafic) et donc n’est pas capable de l’influencer. Ce mode est idéal pour tester le WAF dans l’environnement sans nuire au trafic. Le trafic est répliqué au niveau 1 (couche physique) de la couche ISO/OSI.

Le mode bridge

Le mode bridge est similaire au mode passif. Le WAF fonctionne comme un switch au niveau 2 (couche liaison de données) de la couche ISO/OSI. Ce mode offre des performances élevées et pas des changements importants au niveau de l’infrastructure réseau puisque le WAF n’as même pas besoin d’une adresse IP. Ce mode a quelques inconvénients ; il n’est pas possible de fournir des services de cache.

Le mode routeur

A WAF en mode routeur agit comme un routeur au niveau 3 (couche réseau) de la couche ISO/OSI donc le WAF est en ligne directe avec le trafic Internet. C’est possible en ce mode de remplacer directement un router existant même si ce n’est pas conseillé.

Le mode reverse-proxy

Le mode reverse-proxy est le déploiement le plus courant et riche en fonctionnalités. En ce mode, le WAF se trouve en ligne directe avec le trafic venant de l’Internet. Le WAF a une adresse IP publique et toutes les requêtes concernant les applications web lui y sont directement adressées. Le WAF ensuite fait la requête au serveur web au nom du navigateur d’origine. L’inconvénient d’un mode reverse proxy est qu’il peut augmenter la latence des applications web.

Le mode embarqué

Dans ce mode le WAF est embarqué dans le serveur web comme un module logiciel. Cette approche a certains avantages pour le déploiement des applications web de complexité réduite parce que aucun matériel supplémentaire n’est nécessaire. Pourtant, pour des raisons de scalabilité c’est recommandé d’installer le WAF sur un serveur web indépendant.

Au cours des dernières années, une tendance claire se dégage au sein du paysage de la sécurité de l’information; les applications Web sont l’objet d’attaques.

Les applications Web continuent d’être un des principaux vecteurs d’attaque
pour les criminels, et la tendance ne montre aucun signe de ralentissement.

En effet, de plus en plus, les pirates évitent les attaques réseau au profit d’attaques par cross-site scripting (XSS), d’injections SQL et de nombreuses autres techniques d’infiltration destinées à frapper plus haut dans le modèle OSI, au niveau de la couche applicative en général, et du Web en particulier.

Aujourd’hui la plus part d’architectures réseaux sont protégées contre des attaques venant de l’extérieur par des firewalls classiques. Mais dans le plus part des cas, les ports http/https ne sont pas du tout protégées ou filtrées. C’est dans ce contexte que les pare-feu applicatifs web (WAF) on vus le jours.

Un pare-feu applicatif Web (WAF) est une application ou une appliance
qui surveille les conversations entre un navigateur client et un serveur web au niveau des packages http. Le WAF a la possibilité d’appliquer des politiques de sécurité fondées sur une variété de critères, y compris des signatures d’attaques connues.

Le pare-feu applicatif Web est donc destiné à prévenir les attaques là où les pare-feu réseau et les systèmes de détection ou de prévention des intrusions cessent d’être efficaces. A noter aussi qu’une mise à jour de la norme PCI DSS (Payment Card Industry Data Security Standard), effective depuis juin 2008, exige de sécuriser les applications Web via l’analyse du code ou des firewalls WAF.

Déni de service

La méthode est d’utiliser un réseau de bots pour générer un flux de requêtes vers une application. L’exemple le plus simple est d’envoyer simultanément des milliers de requêtes sur la page d’accueille d’un site public pour rendre hors service le serveur web.

En fonction du type d’application, une requête sur une page dynamique génère sur le serveur et la sur la chaine applicative (serveur d’application et base de données) une charge conséquente (génération des requetés SQL, appel a d’autres instances d’applications telle qu’un service web). Lancer le traitement de cette chaine plusieurs milliers de fois par seconde est en général fatal, le composant le plus faible cédant en premier, en rendant alors l’application indisponible.

Élévation des privilèges

Pour mener cette attaque, il faut que l’attaquant soit déjà connecté sur l’application avec un compte utilisateur. Avec ce compte, il part à la découverte de l’application et tente d’accéder a des fichiers de configuration ou de mot de passe. Par exemple les répertoires suivantes peuvent être accèdes pour tenter d’y découvrir des fichiers de configuration, comptes administrateurs : « /system/ » ; « /passwords/ » ; « /logs/ » ; « /admin/ ».

Injection de code

Une injection de code se produit quand un utilisateur envoie du code au serveur et l’oblige de l’exécuter. Les attaques le plus connus par l’injection du code sont l’injection du SQL et l’injection du PHP.

Une attaque par injection SQL se compose d’insertion d’une requête SQL dans les données  envoyées par le client au serveur. Une attaque réussi  peut lire les données sensibles à partir de la base de données, modifier les données de base de données (INSERT / UPDATE / DELETE), exécuter des opérations d’administration sur la base de données (telles que l’arrêt du SGBD), récupérer le contenu d’un fichier présent sur le système de fichiers de la base de données et dans certains cas d’emmètre des commandes au système d’exploitation.

L’injection PHP est similaire à l’injection SQL mais on remplace le code SQL par du code PHP.

Cross-Site Scripting (XSS)

Une application web est vulnérable aux attaques de type XSS quand un attaquant peut forcer l’application de lui retourner des données soumises non altérées. Ce mécanisme lui permet d’insérer des chaines de caractères spéciales dans la page HTML retournée par le serveur.

Un exemple d’une chaine de caractères spéciale est : <script>alert(« XSS« ) ;</script> qui auras comme résultat l’affichage d’une fenêtre dans le navigateur.

Vol de session HTTP

Un utilisateur d’une application web a le control complet sur la réponse qu’il envoie au serveur. Cette affirmation est spécialement vrais pour les éléments qui stockent de l’information d’état d’une page web comme les cookies http, les champs http cachés, les entêtes http et tous les éléments http  qui peuvent être contenus dans un formulaire http.

Le protocole http est un protocole « sans états » : rien ne permet de lier entre elles les requetés provenant d’un même utilisateur. Les applications utilisent massivement les cookies pour palier ce problème. Les cookies présentent deux vulnérabilités :

• Les cookies sont facilement manipulable à l’aide d’outils comme Fiddler ou Tamper Data. En envoyant des valeurs de cookies « au hasard » ou en utilisant des algorithmes de génération de cookies connus, il est possible de se faire passer par un autre utilisateur.
• Les cookies peuvent être volées et réutilisés. On parle d’attaques par vol de session. Sur un réseau local, un simple « sniffer » suffit pour capturer un cookie. Sur Internet, cette attaque est plus complexe, mais les attaques de type XSS permettent de récupérer des cookies. Ces cookies peuvent être ensuite réutilisées pour qu’un attaquant se fasse passer pour un utilisateur légitime.