Firewalls et applications Web: architecture et sécurisation

Actuellement, aucune entreprise n’envisagerait sérieusement d’ouvrir sur Internet un nouveau service en ligne sans avoir pensé à faire évaluer la sécurité de celui-ci. En effet, la culture de la sécurité commence à faire son chemin dans l’esprit des chefs de projets et des directeurs informatiques, et la dangerosité des attaques provenant d’Internet est quelque chose dont ils sont désormais conscients.

Grâce à ces acquis, les plates-formes hébergeant les applications Web sont de mieux en mieux sécurisées. En particulier, l’utilisation d’un firewall est maintenant considérée comme une condition sine qua non.

Cependant, la présence d'un firewall procure un faux sentiment de sécurité, car il est trop souvent perçu comme la panacée des solutions de sécurité. Or il ne couvre que certains aspects de la protection globale que nécessite une application Web complexe ouverte sur Internet. En particulier, certaines attaques ne peuvent être arrêtées par un firewall, pour la simple raison qu’elles sont noyées au milieu des requêtes de pages Web, qui sont bien sûr autorisées à travers le firewall.

On observe actuellement une recrudescence de ces types d'attaques, car elles sont bien souvent les seules à fonctionner sur une plate-forme bien sécurisée, et elles fonctionnent d’ailleurs extrêmement bien.

Cet article se propose de présenter les mesures à prendre afin de sécuriser une application Web, aussi bien au niveau de son architecture que de son implémentation, contre les différentes attaques capables d'outrepasser un firewall. Nous verrons également la notion de filtrage applicatif, ainsi que les nouveaux logiciels de protection des applications Web de type « reverse-proxy intelligent ».

Une application Web est une application qui n’a besoin que du protocole HTTP ou HTTPS pour être pilotée par un utilisateur. Celui-ci n’a besoin que d’un simple navigateur Web ou d’une application propriétaire utilisant le protocole HTTP/HTTPS.

L’avantage des applications Web est que l’utilisateur peut se situer très loin de l’applicatif et travailler à travers Internet, au besoin par le moyen d’un VPN.

Remarque : contrairement à une idée reçue très répandue, l’utilisation de SSL ne suffit pas à protéger une application Web. Le chiffrement SSL (sans utilisation de certificats clients X.509) ne concerne que la confidentialité, et ne protège pas des intrusions.

La plupart des applications Web sont accessibles depuis Internet, mais un grand nombre d’entre elles sont situées sur des intranets, qui ne peuvent pas non plus être considérés comme des réseaux sûrs.

Pour permettre l’utilisation d’une application Web, il suffit que le firewall protégeant celle-ci ne laisse entrer que le protocole HTTP, en général sur le port TCP 80 (et éventuellement HTTPS sur le port TCP 443). Dans ces conditions, il semble difficile d’attaquer une application Web. Pourtant, nous allons voir qu’à travers ce seul port 80, considéré comme « amical » mais devenu un port « fourre-tout » par lequel passent de plus en plus de flux et de protocoles (DCOM, RPC, SOAP, XML, streaming sur HTTP, …), il est possible de lancer des attaques extrêmement dangereuses.

Les différentes sortes d’attaques sur les applications Web sont les suivantes :

1. Interprétation des URLs

- fichier.ext : fichier lu ou exécuté (son extension .ext est très importante)

- param1 et param2 : paramètres d’exécution, interprétés soit au niveau des composants métiers, soit directement au niveau de la base de données.

· Protocole : on peut essayer de remplacer le protocole https:// par http://, par exemple, afin de désactiver une authentification par certificat client.

· Serveur : on peut le remplacer par son adresse IP ou par les noms de domaines d’autres sites hébergés sur le même serveur, afin d’avoir accès à d’autres parties du site.

· Chemin : on peut tenter de naviguer dans l’arborescence pour accéder à des parties du site non autorisées ou pour remonter dans l’arborescence par l’utilisation de /../../, ou en utilisant des vulnérabilités particulières (le bug Unicode sur IIS, par exemple).

L’URL suivante : http://www.maisjemesoigne.com////////////////…////////////////////// permettait, avec Apache mais aussi avec Vignette, de récupérer la liste des fichiers du répertoire racine, même s’il existait un fichier par défaut (index.html).

· Fichier : son extension va déterminer de quel type d’exécutable il s’agit : CGI, scripts ASP, HTR ou autre code exécutable, etc… Plusieurs types de fichiers ont connu des vulnérabilités attachées à leur mode d’exécution, et en particulier à leur interpréteur. Ainsi, c’est une vulnérabilité dans le filtre ISAPI d’IIS qui interprète les fichiers .IDA/.IDQ qui a permis la propagation du ver CodeRed à partir de l’été 2001.

· Paramètres : la manipulation des noms de paramètres et de leur contenu peut conduire à des effets dangereux. Par exemple, supposons que l’URL suivante prenne comme paramètre un nom de fichier afin d’en afficher la taille :

Les conséquences de ces attaques peuvent être la divulgation d’informations importantes, l’accès au code source des scripts ou au contenu des fichiers, l’exécution de commandes sur le serveur, ou même l’obtention d’un shell sur le serveur, éventuellement sous un compte privilégié (SYSTEM sur Windows NT/2000/XP, par exemple). Des attaques dérivées peuvent être ensuite menées d’après la lecture du code source obtenu ou grâce à des pages trouvées par exploration de l’arborescence.

Pour contrer les attaques ci-dessus, il convient de prendre en compte les recommandations de sécurisation suivantes :

· Sécuriser le système d’exploitation et le serveur Web (appliquer en particulier les derniers patches de sécurité, chrooter le service, …) : voir MISC No 1

· Installer l’arborescence Web sur une partition séparée de la partition système

· Contrôler strictement l’arborescence Web et supprimer les répertoires inutiles

· Supprimer tous les filtres, interpréteurs de scripts, CGI et autres exécutables inutiles

· Supprimer tous les fichiers inutiles sur un serveur de production, notamment les pages d’exemples

· Appliquer des permissions d’accès strictes sur les fichiers au niveau du serveur Web mais aussi du système de fichiers. En particulier, l’utilisateur anonyme ne doit avoir que des permissions en lecture sur les pages statiques.

· Utiliser un filtre d’URLs (par exemple le module mod_rewrite pour Apache ou le filtre ISAPI URLScan pour IIS) et appliquer des règles strictes afin de contrôler, de réécrire ou d’interdire toutes les URLs contenant des caractères dangereux comme les caractères Unicode.

· Installer un reverse proxy (module mod_proxy d’Apache, par exemple) : voir le paragraphe 6 sur le filtrage applicatif.

· Enfin, envisager l’installation d’un IDS sur la DMZ hébergeant le serveur Web et/ou le reverse proxy, afin de détecter les attaques classiques comme la remontée dans l’arborescence Web.

2. Mauvais Contrôle des données entrées par l’utilisateur

Au cours de nos audits et tests d’intrusion, nous rencontrons encore trop souvent des applications Web où le contrôle des entrées par l’utilisateur se fait uniquement côté client. Dans ce cas, il faut toujours considérer qu’un attaquant pourra outrepasser le contrôle côté client et donc envoyer les données qu’il désire au serveur, à l’aide d’un proxy intrusif par exemple. La règle à adopter est de ne jamais faire confiance à du code tournant côté client, comme des applets Java par exemple. En effet, ce code pourra toujours être décompilé, analysé et modifié pour effectuer les tâches voulues par un attaquant.

Considérons le cas d’une page Web permettant d’effectuer un virement bancaire. Par précaution, la banque limite les virements par Internet à 10000 Euros. D’ailleurs, un script Javascript contenu dans la page HTML contrôle en temps réel le montant saisi et empêche toute validation avant que le montant soit correct.

Dans ces conditions, il suffit de modifier le script, ou même simplement de désactiver Javascript, pour pouvoir saisir un montant de 1 000 000 Euros et valider le formulaire.

La recommandation qui s’impose est donc de toujours contrôler la validité des données fournies par l’utilisateur au moins côté serveur. Ce contrôle peut bien sûr être doublé côté client pour des raisons d’ergonomie, mais le contrôle final devra toujours avoir lieu côté serveur.

D’autre part, il existe des caractères spéciaux dont la signification, au sein d’une chaîne alphanumérique, peut respecter une syntaxe particulière au niveau d’un langage de programmation ou d’un système d’exploitation, ce qui peut conduire à l’exécution de commandes hostiles. Ces caractères figurent parmi les suivants :

Ainsi, dans l’exemple fourni au paragraphe 1, le caractère « * » était interprété sur UNIX comme l’ensemble des fichiers contenus dans le répertoire courant. De même, le caractère « ; » est un séparateur, les caractères « < » et « > » effectuent des redirections, « % » permet d’entrer des caractères par leur code hexadécimal, etc…

Il est donc indispensable de filtrer ces caractères à l’intérieur des données fournies par l’utilisateur, en les codant en leurs équivalents en HTML (« > » devient &gt ; , « < » devient &lt ;, etc…), ou en leur ajoutant un caractère d’échappement (« \ » par exemple), ou encore en les supprimant, ou enfin en refusant purement et simplement la transaction en demandant à l’utilisateur de modifier sa saisie.

Pour résumer, les recommandations nécessaires pour contrer la saisie de données hostiles par un utilisateur sont les suivantes :

· Vérification de la validité réelle des données (en relatif, dans une base de données)

Ceci permet d’éviter les attaques de type force brute et peut s’implémenter par exemple en multipliant à chaque fois le temps d’attente avant la fin de la transaction par deux entre deux transactions identiques.

3. Injection SQL

L’injection SQL peut être une conséquence directe d’un mauvais contrôle des données entrées par l’utilisateur. En effet, les caractères « ‘ » et « ; » peuvent être utilisés pour enchaîner plusieurs requêtes SQL à la suite. Considérons par exemple une page HTML comprenant un champ de saisie nommé « Name » permettant d’obtenir les coordonnées des clients d’une entreprise. La requête SQL tournant sur le serveur est la suivante :

SELECT * FROM table_Clients WHERE champ_Nom=toto ; INSERT INTO table_Users VALUES ('Mon_login', 'Mon_password')

Le résultat est l’affichage des données concernant le client toto, suivi par l’ajout dans la base de données d’un utilisateur dont le couple login/mot de passe permettra à l’attaquant de se connecter à l’application comme un utilisateur authentifié.

Le cas le plus simple d’injection SQL consiste à s’authentifier dans une application Web en saisissant un login existant et n’importe quel mot de passe suivi de « OR 1=1 » :

L’authentification étant vérifiée par comparaison, le résultat booléen de la vérification du mot de passe est toujours vrai, ce qui permet d’obtenir l’accès à l’application.

Il faut noter que le filtrage des caractères spéciaux ne suffit pas à se protéger contre l’injection de code SQL. En effet, considérons la saisie suivante :

toto UNION ALL SELECT champ_Password FROM table_Users WHERE champ_Login LIKE admin

Aucun caractère spécial (autre que le “_” utilisé pour des raisons de lisibilité) n’est utilisé, et pourtant la requête obtenue récupère la liste des mots de passe des administrateurs.

Certains gestionnaires de base de données offrent des fonctions supplémentaires potentiellement dangereuses. Par exemple, Microsoft SQL Server possède par défaut un certain nombre de procédures stockées d’administration pouvant conduire à des fuites d’information et à des intrusions. Voici quelques exemples de saisies potentiellement dangereuses :

Il existe donc beaucoup de techniques d’injection de code SQL. Pour contrer ce type d’attaques, il est nécessaire d’effectuer un filtrage beaucoup plus précis du contenu des données saisies par les utilisateurs. Il faudra en particulier interdire les mots clés comme SELECT, INSERT, UNION, LIKE, etc… L’utilisation de fonctions de substitution et d’expressions régulières est ici très utile.

Il est nécessaire ensuite de sécuriser la configuration du service de base de données :

· Suppression des comptes inutiles créés par défaut et création de comptes avec des privilèges réduits (tous les utilisateurs authentifiés ne doivent pas utiliser le même compte pour effectuer toutes les transactions dans la base de données)

· Application de permissions d’accès en lecture, suppression, exécution sur les tables, les procédures stockées et les autres objets de la base de données.

Il convient enfin de rédiger toutes les requêtes SQL de son application avec soin, en utilisant une syntaxe la plus stricte possible, avec typage systématique (chaînes entourées de « ‘ » par exemple) et vérifications de conformité aux différents stades de traitement des requêtes, aussi bien au niveau des composants métiers (éventuellement transactionnels, comme dans MTS) que des procédures stockées éventuelles dans la base de données.

4. Attaques sur les identifiants de session

Contrairement au paradigme client/serveur traditionnel, le protocole HTTP est un protocole déconnecté. C’est-à-dire qu’entre deux requêtes successives, la connexion entre le client et le serveur est coupée. Le serveur ne peut donc pas reconnaître un client qui s’est déjà connecté et qui a commencé une transaction dans l’application Web.

Pour remédier à cela, la plupart des systèmes d’authentification et de maintien du contexte des sessions Web des utilisateurs repose sur un identifiant de session, échangé à chaque page entre le client et le serveur, que ce soit au niveau du cookie, de l’URL ou d’un champ caché de formulaire. Le serveur maintient un contexte de transaction pour chaque identifiant de session généré.

Une attaque classique consiste à voler la session d’un utilisateur qui vient de s’authentifier sur le système en essayant de deviner la valeur de son identifiant de session. Si la valeur de celui-ci est découverte, un attaquant peut alors utiliser l’application Web en lieu et place de l’utilisateur légitime en injectant l’identifiant récupéré dans sa propre session, à l’aide d’un proxy intrusif par exemple.

Si on essaie de récupérer un grand nombre d’identifiants successifs, on obtient par exemple les valeurs suivantes :

On remarque immédiatement que cet identifiant de session, dont le jeu de caractères est limité, semble codé en base 32, et qu’il possède de nombreuses parties fixes ou variant lentement. Après une analyse plus poussée, les parties fixes sont identifiées comme étant des adresses IP et des ports. Enfin, il semble que des parties varient comme une horloge interne.

A l’aide de ces simples constatations, il est possible de développer un outil qui va nous permettre de diminuer considérablement l’espace de valeurs de cet identifiant, et qui va automatiser la recherche d’une valeur valide de celui-ci. On peut ainsi augmenter les chances de trouver une bonne valeur à une sur 1000 à 3000, ce qui est extrêmement peu : quelques minutes seulement permettront de voler la session d’un utilisateur authentifié !

Il est donc indispensable de vérifier la qualité du générateur aléatoire et l’étendue de l’espace de valeurs des identifiants de session de son application Web. Cette étendue doit être suffisamment grande pour qu’une attaque en force brute ne puisse pas être menée dans un délai réduit.

Il est déconseillé d’utiliser les fonctions de génération d’identifiants fournies en standard avec certains logiciels ou environnements de développement du marché (cf l’exemple réel ci-dessus, obtenu avec un logiciel utilisé dans le domaine bancaire). Il est parfois préférable d’écrire soi-même une fonction de génération des identifiants de session plus robuste, mais qui devra être vérifiée soigneusement.

5. Cross Site Scripting

Le principe du Cross Site Scripting (CSS ou XSS) est d’attaquer les utilisateurs de l’application plutôt que l’application elle-même. Pour cela, l’attaquant provoque l’envoi à la victime, par le site Web légitime, d’une page hostile contenant des scripts ou des composants malveillants.

Cette page est exécutée sur le poste de la victime, dans le contexte du site Web d’origine (Internet, sites de confiance, …), et dans le contexte de sécurité de l’utilisateur courant.

L’exemple le plus simple est celui qui consiste à provoquer une erreur HTTP 404 chez les victimes. Si le site www.mabanque.com ne filtre pas de façon correcte les données envoyées par les utilisateurs, un attaquant va saisir le texte suivant sur une page accédée par d’autres utilisateurs :

<A HREF=http://www.mabanque.com/<script> alert(document.cookie)</script>">Click Here</a>

Les internautes recevront la page suivante s’ils ont cliqué sur le lien ci-dessus :

Le script contenu dans cette page d’erreur 404 va provoquer l’affichage des cookies relatifs au site www.mabanque.com. Il suffit à un attaquant de les récupérer pour se faire passer ensuite pour l’utilisateur légitime auprès du site de la banque.

Exemple de Cross Site Scripting permettant de récupérer l’identifiant d’un utilisateur

Ce type de vulnérabilité est présent sur de nombreux sites, forums et webmails qui interprètent automatiquement le code javascript envoyé dans leurs pages. De nombreuses vulnérabilités de ce genre, extrêmement simples à exploiter mais difficiles à filtrer, ont fait les gros titres dans des publications triviales et nombrilistes. Il est évident que la lutte contre le filtrage des codes mobiles hostiles est sans fin.

· Contrôler la validité des saisies des utilisateurs, notamment les balises <script>, les incohérences du type <img src="javascript:… ">, etc…

Ce contrôle peut également être fait au niveau des antivirus côté serveurs effectuant également un contrôle sur le flux HTTP (comme WEBSweeper de ClearSwift par exemple).

· Maintenir les navigateurs et clients mail à jour (correctifs de sécurité) ;

6. Autres attaques

D’autres attaques traversant les firewalls peuvent être menées contre des applications Web :

A éviter : les applications utilisant ces technologies sont sujettes à des manipulations effectuées côté client permettant à un attaquant d’outrepasser le mécanisme d’authentification.

A éviter : la manipulation des headers à l’aide d’un proxy intrusif est facile.

A éviter : le manque de ré-authentification au niveau de certaines fonctionnalités critiques (comme le changement de mot de passe par exemple) permet souvent à un attaquant de prendre le contrôle d’un compte utilisateur.

La mauvaise gestion du contexte utilisateur peut permettre une augmentation progressive de privilèges conduisant à la prise de contrôle total de l’application par un attaquant. Il convient de contrôler strictement et à chaque page le contexte de sécurité (l’utilisateur est-il authentifié ? Quels droits a-t-il ?).

Il s’agit d’attaquer directement les utilisateurs de l’application plutôt que l’application elle-même. Ce genre d’attaques est rendu possible principalement par les langages exécutés côté client :

Là encore, il est indispensable de maintenir les navigateurs et clients mail à jour et de les sécuriser le plus possible.

Une attaque dite “man in the middle” consiste à intercepter les requêtes du client et à les relayer vers le serveur distant légitime et inversement à intercepter les réponses du serveur et à les relayer vers le client. Il est possible au passage, si nécessaire, de modifier à la volée les données fournies par le client et/ou les réponses du serveur.

Cette attaque est même possible si le serveur de destination utilise un chiffrement par SSL : il suffit que le serveur intercepteur possède lui aussi un certificat serveur et que le client clique sur « Accepter » lorsque son navigateur lui propose d’utiliser ce certificat pour dialoguer avec le serveur distant légitime. C’est ce que fera tout utilisateur qui ne sera pas au fait des problèmes de sécurité. Il ne reste plus alors au serveur intercepteur qu’à déchiffrer d’un côté et rechiffrer de l’autre, à la volée.

Le seul moyen de se prémunir contre ce type d’attaque est d’imposer une authentification côté client par l’utilisation de certificats clients X.509. Le serveur intercepteur ne pourra alors plus se faire passer pour le client auprès du serveur distant légitime car il ne dispose pas de la clé privée du client.

7. Filtrage applicatif

Le filtrage applicatif, comme son nom l’indique, consiste à effectuer un filtrage des requêtes et des réponses non pas au niveau réseau (couche OSI 2 pour Ethernet au niveau d’un switch par exemple, couche 3 pour IP, couche 4 pour TCP et UDP au niveau d’un firewall) mais au niveau application (couche OSI 7). Le filtrage applicatif suppose donc la connaissance de l'application et de ses protocoles afin de connaître la structure des données échangées.

Dans notre cas particulier des applications Web, il s’agit d’interpréter intégralement le protocole HTTP pour en extraire les URLs, les headers, les cookies, les authentifiants, etc…

L’avantage du filtrage applicatif apparaît donc clairement : les règles utilisées à ce niveau peuvent se fonder sur tous ces paramètres de niveau élevé et permettre un filtrage beaucoup plus élaboré qu’un simple filtrage TCP/IP. Il s’agit en fait d’un filtrage de contenu. Celui-ci peut aller jusqu’au filtrage du code mobile hostile véhiculé dans les pages HTML, sous forme de scripts Javascript ou d’ActiveX, comme nous l’avons vu.

Le filtre applicatif HTTP couramment utilisé pour la protection d’une application Web est le « reverse proxy », appelé aussi relais inverse. Il s’agit d’un relais applicatif agissant en coupure, qui va s’intercaler entre le serveur Web et les clients extérieurs. C’est le reverse proxy qui répond aux requêtes des clients, et c’est lui qui effectue les requêtes vers le serveur Web final : il se comporte donc comme un serveur HTTP vis-à-vis des clients et comme un client HTTP vis-à-vis du serveur Web.

Remarque : au niveau du firewall, l’accès direct au serveur Web doit bien sûr être interdit depuis l’extérieur. Seule une règle autorisant les accès au reverse proxy sur le port TCP 80 et/ou le port TCP 443 devra être présente.

Un reverse proxy permet en particulier de faire respecter les contraintes suivantes au niveau de l’accès au serveur Web :

o L’exécution des fichiers dont les extensions sont explicitement autorisées

o L’utilisation de paramètres dont le type et le contenu sont autorisés pour chaque objet métier de l’applicatif.

Actuellement, de nouveaux logiciels de protection des applications Web, qui agissent comme des reverse proxies intelligents, sortent sur le marché.

8. Logiciels de protection des applications Web

Le nombre considérable d’attaques Web traversant les firewalls a conduit plusieurs éditeurs à concevoir des logiciels de protection des applications Web s’intercalant entre Internet et le serveur Web hébergeant l’application. Ils agissent ainsi comme des reverse proxies intelligents et permettent de stopper certains types d’attaques.

Ces produits permettent de protéger les applications Web contre les attaques suivantes :

· Attaques par l'utilisation de méthodes HTTP particulières (OPTIONS, PUT, …)

· Attaques par modification du contexte de transaction (champs cachés, champs pré-saisis, cookies, …)

De plus, ces produits permettent une pré-configuration automatique des règles de sécurité et un apprentissage, automatique ou non, des applications Web à protéger (chemins de navigations types entre les pages par exemple).

Ces solutions ne sont pas encore répandues mais font actuellement l'objet d'un marketing agressif qui devrait augmenter leur pénétration.

Cependant, ces produits sont encore un peu jeunes et parfois compliqués à configurer, d’autant plus qu’à chaque modification, même mineure, de l’application, il est indispensable de modifier également la configuration du produit. Mais on peut imaginer que si leurs modules d’apprentissage se perfectionnent suffisamment, ces produits rencontreront un grand succès dans un proche avenir, au même titre que les firewalls il y a quelques années. Deviendront-ils aussi incontournables ? L’avenir nous le dira.

En conclusion, nous avons vu que le nombre d’attaques qu’il est possible de mener contre une application Web et qui traversent les firewalls est considérable. Il est donc extrêmement important de prendre en compte la sécurité le plus en amont possible lors du développement d’une application Web. L’idéal est de considérer les contraintes sécuritaires dès la conception de l’architecture de l’application. Les recommandations exposées dans cet article permettront alors de bloquer la plupart des attaques. Cependant, il reste indispensable de faire procéder à un test d’intrusion applicatif par une société spécialisée, à la fin du développement et juste avant la mise en production de l’application Web. Enfin, il est important d’effectuer un suivi de la sécurité tout au long de la vie de l’application Web, notamment lors de la mise en ligne de chaque nouvelle version.

http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf

Consultant Senior en sécurité Windows NT/2000/XP, audits et tests d’intrusion.