Protection contre les dénis de service

Cette protection est assez délicate à mettre en œuvre du fait de la variété des méthodes utilisées pour générer un déni de service. Il existe deux types de solutions.

La première se base sur un contrôle comportemental. Différents paramètres sont surveillés : nombre des requêtes par seconde (par utilisateur ou au global), temps de réponse des serveurs, etc. Et des seuils de dépassement sont configurées (ex : augmentation de 200% de temps de réponse moyen d’un serveur). Lorsque ces seuils sont dépassées, des contre-mesures sont mises en place : limitation du nombre de requêtes par seconde, blacklisting de certains sources des requêtes.

Une autre protection utilise des mécanismes de détection des bots ou vers. Pa exemple, un Javascript est injecté dans chaque réponse émise par le serveur. Si le client répond au Javascript, nous avons a faire à un browser (pas forcement honnête), dans l’autre cas, nous avons affaire à un script de génération de requête et nous allons pouvoir d’ores et déjà restreindre son activité ou dérouter son trafic soit en le bloquant soit en le l’envoyant ailleurs (ex : honeypot pour récupérer plus d’informations sur l’attaquant).

Protection contre les élévations de privilèges

Il est possible de protéger une application de cette attaque via des « white-lists » : des règles spécifiant quel contenu doit être accédé sur l’application. Toute requête ne respectant pas ces règles sera rejeté. Il est possible de définir ces contenus selon différents critères :

• Type d’objets : php, aspx,html, css, js, etc. Toutes les requêtes à destination des objets de types conf, sh, dll, exr, pl,… seront bloquées.
• URL : seules les requêtes a destination du chemin «/public/ » (par exemple) sont autorisées et ainsi les requêtes sur les path « /conf/ », « /logs/ », « /admin/ », « /root/ »,… seront bloquées.
• Objets : dans ce cas les objets ne sont plus définis par leur type mais de manière unitaire : index.php, home.asp,… Cette méthode est plus précise, mais plus complexe à maintenir, bien que des outils de découverte et d’apprentissage des applications puissent faciliter l’exploitation.

Protection contre l’injection du code

Pour se protéger contre l’injection du code et spécialement de l’injection du code SQL, plusieurs méthodes peuvent être utilisées et combinées :

• Mise en place de signature d’attaques : bien qu’il existe une infinité de combinaisons pour procéder à une injection SQL, certaines sont connues et peuvent être facilement identifiées à l’aide d’une expression régulière. Tout contenu de la requête (en général les données d’un POST HTTP) matchant la signature provoquera le blocage de la requête.
• Inspection des données envoyées à l’application : les injections étant très souvent véhiculées par un POST http ou dans un URL, il est intéressant de soumettre ces données à un contrôle des caractères envoyées. 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 permettent de se prémunir contre ces attaques.

Protection contre les Cross-site Scripting

De la même manière que pur sécuriser une application contre les injections SQL, il est possible d’implémenter des règles de contrôle de données envoyées a travers un POST http ou dans les paramètres en interdisant des caractères de type « < », « > », « / », …

Protection contre les vols de sessions  HTTP

Les attaques utilisant un vol de cookie peuvent être contrées de plusieurs manières qui peuvent être combinées pour obtenir le meilleur niveau de sécurité :

• Chiffrement SSL : le chiffrement permet d’éviter (en tout cas de compliquer) le vol de cookies par un sniffer sur un réseau local. En effet, même si le trafic est capturé, les données ne seront pas exploitables. Une variante consiste à ne chiffrer que le contenu du cookie qui devient ainsi inexploitable. Si le serveur ne possède pas cette capacité, le WAF peut réaliser cette opération en chiffrant le contenu du cookie lors de son envoi vers le client et en le déchiffrant avant de l’envoyer au serveur.
• Protection contre les attaques XSS : un des moyens les plus utilisés pour voler un cookie est de procéder à une attaque XSS.

Le « Web Application Security Consortium » (WASC) est une organisation a but non lucratif constitué des industriels et des représentants des organisations qui produisent des logiciels libres qui a comme but a faire connaître les meilleures pratiques concernant la sécurité du web.

Parmi les projets menés par WAFEC il y a :

• The Web Hacking Incidents Database (WHID) : projet dédié au maintien d’une liste d’incidents liées a la sécurité des applications web.
• The Web Application Security Scanner Evaluation Criteria (WASSEC) : est un ensemble de lignes directrices pour évaluer des scanners pour des application web.
• The Script Mapping Project : Le but du projet est de fournir avec une liste exhaustive des vecteurs pour exécuter des scripts dans une page web sans l’utilisation de la balise <script>.
• Web Security Glossary : Le projet est un index alphabétique des termes et la terminologie relatives à la sécurité des applications Web. Le but de ce glossaire est de clarifier davantage le langage utilisé au sein de la communauté

Concernant les WAFs, WASC mène le projet WAFEC (The Web Application Firewall Evaluation Criteria). Le but de ce projet est de développer une analyse détaillée des critères d’évaluation des WAF et la mise en place d’une méthodologie de test qui peut être utilisé par n’importe quel technicien raisonnablement compétent pour évaluer indépendamment la qualité d’une solution WAF.

Le WAFEC sert deux objectifs : d’une part il aide les utilisateurs à comprendre ce qu’est un WAF est quel et son rôle dans la protection des sites web et d’autre part, WAFEC fournit un outil pour les utilisateurs à prendre une décision éclairée lorsque ils choisissent un WAF.

La première version de WAFEC été publié en 2006 et est la première ressource qui a fourni la définition d’un WAF. WAFEC est couramment utilisé par des organisations lors de l’évaluation d’un WAF.

Le WAFEC contiens les critères suivants :

• L’architecture de déploiement : cette section met en évidence les questions clé pour déterminer la faisabilité du déploiement de pare-feu d’applications Web dans un environnement donné.
• Le support HTTP et HTML : cette section énumère les versions du protocole HTTP et HTML qui doivent être supportées par les WAF.
• Les techniques de détection : section contenant les technique de détection possibles, model de sécurité positif, model de sécurité négatif, model de sécurité basé sur les signatures.
• Les techniques  protection : cette section énumère les exigences spécifiques pour la protection qui ne sont pas couvert en utilisant des mécanismes de protection génériques décrites dans d’autres sections.
• La journalisation : cette section énumère les exigences spécifiques pour la journalisation des évènements générés par le WAF, le format de logs (text, XML, API), comment les administrateurs peuvent être notifiés (email, SMTP Trap, API).
• Les rapports générés par le WAF : section contant des informations sur le rapports génères par le WAF, le format du rapport (HTML, XML, PDF), les mécanismes de distribution des rapports (email, FTP).
• Le management : section contenant les critères pour manager le WAF, l’habilité d’accepter manuellement les faux positives, l’habilité de appliquer des politiques par application, l’habilité de customiser les signatures d’attaques.
• La performance : sections contenant des informations sur la performance au niveau HTTP, la niveau HTTPS (SSL), la performance sur
• Les services web : les caractéristiques des WAFs concernant les services web, est-ce que le WAF protège des services web, est-ce que le WAF valide les appelles a des services web.

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.