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.