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.