Les sites Web sont  majoritairement  utilisés par les entreprises et collectivités comme vecteur de communication, mais sont également très répandus pour le commerce en ligne (B2B ou B2C). Ces ressources Web sont hébergées dans les centres de données internes à l’organisation, ou hébergées sur le nuage.

Mettre en ligne un site Web, quelle que soit sa fonction, nécessite donc d’avoir une approche sécurisée, car les sites Web sont les points d’entrées visibles de l’Internet, et donc la cible privilégiée pour les assaillants.

 Même ceux n’hébergeant pas leurs serveurs Web peuvent être la cible d’attaques menées sur des chemins d’attaques engendrés par la communication entre l’application Web et des composants d’infrastructure (annuaire, base de données, serveur d’authentification, etc.).

Certains clients me disent ne pas avoir de ressource Web publiées sur Internet. Pourtant, ces mêmes clients disposent de serveur WebMail pour l’accès des nomades à leur messagerie. Un WebMail n’est-il pas un serveur Web, exposant votre entreprise aux mêmes failles qu’un site de e-commerce ?

Surface d’attaque d’un serveur Web

Les serveurs Web sont généralement des frontaux exempts de données confidentielles. Les attaques envers les serveurs Web permettent donc aux pirates de s’ouvrir une porte vers votre SI, dans l’optique d’y dérober de l’information utile par un jeu de rebond.
Sécuriser un serveur Web est une tâche à prendre au sérieux, et dans une optique globale de sécurité. La protection du serveur en tant que telle est importante pour garantir l’intégrité des données présentées aux Internautes, et ainsi garantir l’image de votre entreprise. Idéalement, une analyse de risque sur les chemins d’attaques d’une application Web devrait être réalisée, afin de définir un niveau de risque et d’acceptabilité face à la menace, son préjudice et la probabilité de l’exploiter.

De nombreuses attaques existent pour tenter de faire « plier » un serveur Web, parmi les plus connues les injections de code SQL, le cross scrip scripting, les buffers overflow etc.

Sécuriser ses serveurs Web

Les briques d’infrastructures sont essentielles afin de sécuriser un serveur Web. Parmi ces briques, on y trouve les incontournables pare-feux et sonde IDS, la segmentation en DMZ, sans oublier la sécurité du serveur Web lui-même pour en réduire la surface d’attaque sur les couches systèmes et moteur Web.

Sécuriser un serveur Web relève donc de plusieurs aspects. Il y a certes les aspects techniques à prendre en compte, gravitant autour de la sécurité périphérique, mais il est tout aussi important de garder à l’esprit que les briques d’infrastructures ne remplacent pas les principes de développements sécurisés (outils et méthodes de développement sécurisé, gestion du cycle de vie du logiciel). Elle permet de ralentir une attaque, ou décourager les pirates les moins aguerris ou motivés. Il est donc important d’intégrer dans sa politique de protection des applications Web la sécurisation du développement de l’application, en respectant l’état de l’art en la matière (revue de code, gestion des entrées, réduction des privilèges, accès aux données …..).

Le développement des applications Web n’étant pas forcément maitrisé par vous-même, car avez sous-traité son développement, il est donc important d’avoir des briques de sécurité d’infrastructure robuste.

Le WAF (Web Application Firewall) et les firewalls XML, sont à ce jour une brique de sécurité trop méconnue et pourtant essentielle. La faiblesse du protocole http, et l’usage qui en est fait comme enveloppe de communication, ne permet pas aux mécanismes de pare-feu ou reverse proxy classiques d’apporter un niveau de sécurité suffisant face aux menaces actuelles. Les WAF sont des pare-feu de sécurité dédiés sur la couche applicative protégeant les sites Web publiés selon deux approches différentes et parfois complémentaires :

philippe-maton–          Une sécurité dite positive, consistant à créer une liste blanche des requêtes autorisées. Cette approche, très sécurisée, nécessite une bonne connaissance du développement de l’application Web (certaines solutions WAF font de l’auto apprentissage du site en fonctionnement normal), et un suivi dans le cycle de vie de l’application nécessitant une extrême rigueur. En effet, tout ajout de fonctionnalité, de correction de bug etc. nécessite la mise à jour de cette liste blanche.

–          Une sécurité dite négative, consistant à bloquer les requêtes s’apparentant à des attaques, sur la base de signatures. Cette méthode est plus simple et plus souple à mettre en œuvre que la méthode positive, mais aussi moins sécurisée.

Une approche combinée entre ces deux méthodes relève de l’idéal.

 

Article rédigé par Philippe MATHON – Directeur Technique Sécurité.

Vous vous sentez concerné par la protection de vos serveurs Web ? Vous voulez en savoir plus ? Postez votre commentaire !