BLOGUE – Ce billet est la suite du billet « Avez-vous défini les critères de sécurité de vos applications web? ». En effet, après avoir défini ces critères de sécurité, il faut mettre en place quelques règles techniques pour protéger vos applications. Aujourd’hui, je souhaite revenir sur les questions essentielles à se poser pour protéger une application web.
Pourquoi est-il si important de bien sécuriser une application web?
Les serveurs et les réseaux sont de mieux en mieux protégés. Les vulnérabilités se sont donc déplacées vers un maillon plus sensible : les applications web. Vous rencontrez très souvent des applications web : lorsque vous vous connectez au site Internet de votre banque pour consulter le solde de votre compte, ou lorsque vous réalisez un achat sur la toile. Dans ces deux cas, et dans bien d’autres, l’application en ligne à laquelle vous accédez est susceptible de contenir des données confidentielles. Il convient donc de lui apporter un niveau maximal de sécurité.
Quelle architecture pour une application web?
Les applications sont généralement hébergées dans un modèle reposant sur trois couches (dit 3 tiers).
– La couche de présentation : c’est l’interface utilisateur
– La couche « métier/applicative » : accédée depuis la couche de présentation, elle traite l’information
– La couche de données : c’est le stockage de l’information, accédée par la couche applicative
La maîtrise des flux réseau circulant au sein de cette architecture 3 tiers est essentielle.
Première bonne pratique : installer un pare-feu réseau et utiliser des DMZ
Mettre en place un pare-feu réseau est indispensable pour cloisonner les couches au sein de zones démilitarisées différentes (DMZ). Il est important de contrôler l’ouverture des flux sur ces pare-feu. Par exemple, il est absolument déconseillé d’ouvrir des flux depuis Internet vers la couche « données », cela irait à l’encontre de la sécurité du modèle 3 tiers car les couches « présentation » et « application » sont contournées.
Deuxième bonne pratique : chiffrer les flux
Il est aussi important de vérifier que les flux intercouches soient chiffrés à l’aide de protocoles tels que le HTTPS. Cela permet d’éviter des attaques de l’homme du milieu au sein de ce modèle. Il est à noter qu’il est très important de sensibiliser les utilisateurs à vérifier le certificat du site web. Cela permet d’éviter qu’un utilisateur se retrouve sur un site pirate.
Troisième bonne pratique : limiter les protocoles à risque
Certains protocoles fortement utilisés au sein des environnements Microsoft sont vecteurs de propagations virales. Par exemple, le protocole Netbios est à éviter au sein d’une infrastructure. Si toutefois, il faut ouvrir ce type de flux, il convient de parfaitement cloisonner les différents éléments et de mettre en place un plan d’actions en cas d’attaques virales (par exemple, la possibilité de pouvoir arrêter ce type de flux rapidement en cas de danger à l’aide d’un poste d’administration lui aussi cloisonné). La mise en œuvre d’IPS est aussi un moyen intéressant pour contrer les attaques qui pourraient véhiculer par ce type de flux.
Comment sécuriser l’application web au niveau de l’architecture?
Le pare-feu traditionnel n’étudie pas le contenu des flux qui pénètre dans vos architectures, il ne fait que les autoriser ou les bloquer en fonction de leur provenance. Si la provenance est légitime mais que le contenu du flux est corrompu, alors le risque est réel et non décelable par ce dernier.
Quatrième bonne pratique : installer un pare-feu applicatif (WAF ou Web Application Firewall en anglais)
Cet équipement est déployé en amont de la couche présentation afin de filtrer les attaques applicatives potentielles, telles que des Injection SQL ou les failles XSS.
Le pare-feu applicatif permet de se protéger contre les failles de l’OWASP (Open Web Application Security Project en anglais), qui est un organisme qui recense les dix risques de sécurité applicatifs les plus critiques sur Internet.
Comment fonctionne un pare-feu applicatif (WAF)?
Le pare-feu applicatif se place devant la couche présentation. Tous les flux applicatifs de type HTTP et HTTPS passent donc par lui avant d’accéder à la couche présentation de l’application.
Le filtrage se réalise de deux manières : soit par liste blanche, soit par liste noire.
– La liste blanche : la plus sûre mais la plus difficile à configurer
Son but consiste à autoriser uniquement le trafic sûr et à bloquer tout le reste (tout comme un pare-feu réseau). C’est une tâche difficile pour des applications qui génèrent beaucoup de données aléatoires. De plus, il est quasi impossible de connaître tout le bon trafic, ce qui peut créer des faux positifs. Une liste blanche mal générée risque d’altérer le fonctionnement de l’application.
– La liste noire : la plus simple mais la plus sensible
Lorsque la liste blanche est trop complexe à déterminer, il faut alors opter pour la liste noire.
Son fonctionnement est inverse et consiste à bloquer tout le mauvais trafic identifié et à autoriser le reste. Les pare-feu applicatifs disposent aujourd’hui de fonctionnalités complémentaires, comme la réputation web afin de compléter ce mécanisme et d’être ainsi plus efficace.
Comment renforcer la sécurité d’accès à une application web?
Pour accéder à la couche « présentation», il est aussi fortement recommandé de mettre en place un mécanisme d’authentification forte qui consiste à combiner deux moyens d’authentification (par exemple un mot de passe et une empreinte, ou un mot de passe et un jeton de sécurité).
Cinquième bonne pratique : privilégier une authentification forte
Une authentification faible de type nom d’utilisateur et mot de passe pourrait permettre à un attaquant de réaliser une attaque par force brute et ainsi de pouvoir accéder à l’application directement depuis Internet. Néanmoins, certains logiciels libres comme fail2ban peuvent empêcher les attaques par force brute. Ce système surveille les journaux des applications et bannit les adresses IP qui ont un trop grand nombre d’échecs d’authentification.
A défaut, utiliser des mots de passe différents et complexes pour chaque application, de plus de huit caractères et mélangeant chiffres, lettres et caractères spéciaux. Votre date de naissance est à proscrire, tout comme le nom de votre animal de compagnie ou de vos enfants, trop facilement identifiables sur Internet et les réseaux sociaux!
Dernière question : est-il nécessaire de chiffrer les données de l’application?
Je dirais que tout dépend de quoi on souhaite se protéger. Le chiffrement de données ne sert, à mon sens, qu’à se prémunir contre le vol physique. Le chiffrement ne permet en aucun cas de se prémunir du vol délibéré d’un administrateur, car il dispose des accès et aura donc accès au déchiffrement des données.
Un pirate informatique qui accède à l’application aura lui aussi accès aux données ainsi qu’aux clés de déchiffrement. De plus, le coût engendré par ce chiffrement ainsi que l’organisation à mettre en place ne le justifie pas systématiquement.
En revanche, sur un équipement nomade, l’intérêt de chiffrer est tout autre.
En conclusion, je dirai que les applications web sont une porte d’entrée vers vos systèmes d’informations. La mise en œuvre de ces bonnes pratiques couvrira une majeure partie des risques.
Si en plus vous les associez avec une exploitation vous garantissant des résultats en terme de disponibilité, intégrité et confidentialité de vos données, vous pourrez dormir tranquille!