[PDF] Note technique Recommandations pour la sécurisation des sites web

View - Download Note technique Recommandations pour la sécurisation des sites web

Previous PDF

Next PDF

DAT-NT-009/ANSSI/SDE

P R E M I E R M I N I S T R E

Secrétariat général Paris, le 13 août 2013 de la défense et de la sécurité nationale N oDAT-NT-009/ANSSI/SDE/NP Agence nationale de la sécuritéNombre de pages du document des systèmes d"information(y compris cette page) : 23 Note techniqueRecommandations pour la sécurisation des sites web

Public visé:

DéveloppeurX

AdministrateurX

RSSIX DSI

Utilisateur

Informations

Avertissement

Ce document rédigé par l"ANSSI présente les" Recommandations pour la sécurisation

des sites web ». Il est téléchargeable sur le sitewww.ssi.gouv.fr . Il constitue une production

originale de l"ANSSI. Il est à ce titre placé sous le régime de la " Licence ouverte » publiée par

la mission Etalab (www.etalab.gouv.fr). Il est par conséquent diffusable sans restriction. Ces recommandations sont livrées en l"état et adaptées aux menaces au jour de leur publi- cation. Au regard de la diversité des systèmes d"information, l"ANSSI ne peut garantir que ces

informations puissent être reprises sans adaptation sur les systèmes d"information cibles. Dans

tous les cas, la pertinence de l"implémentation des éléments proposés par l"ANSSI doit être

soumise, au préalable, à la validation de l"administrateur du système et/ou des personnes en

charge de la sécurité des systèmes d"information.Personnes ayant contribué à la rédaction de ce document:

ContributeursRédigé parApprouvé parDate

BSS, BAS, BAI,

FRI, LAMDATSDE13 août 2013

Évolutions du document :

VersionDateNature des modifications

1.022 avril 2013Version initiale

1.113 août 2013Corrections et précisions mineures, notamment

sur TLSPour toute remarque:

ContactAdresse@mélTéléphone

Bureau Communication

de l"ANSSI51 bd de La

Tour-Maubourg

75700 Paris Cedex

07 SPcommunication@ssi.gouv.fr01 71 75 84 04

N oDAT-NT-009/ANSSI/SDE/NP du 13 août 2013Page 1 sur22

Table des matières

1 Avant-propos32 Prévention32.1 Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Architecture

3

2.1.2 Configuration

7

2.2 Code applicatif du site

10

2.2.1 Gestion des entrées

11

2.2.2 Logique applicative

14

3 Réaction193.1 Méta-informations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Détection des incidents

19

3.2.1 Surveillance

20

3.2.2 Journalisation

21

3.3 Conduite à tenir en cas d"incident

21

4 Compléments d"information

22 N
oDAT-NT-009/ANSSI/SDE/NP du 13 août 2013Page 2 sur22

1 Avant-propos

Les sites web sont par nature des éléments très exposés du système d"information. Leur sécurisation

revêt une grande importance, et ce à plusieurs titres.

Les menaces les plus connues pesant sur les sites web sont les défigurations et les dénis de service.

Une défiguration est une attaque par laquelle une personne malveillante modifie le site pour remplacer

le contenu légitime par un contenu qu"il choisit, par exemple pour relayer un message politique, pour

dénigrer le propriétaire du site ou simplement, pour revendiquer son attaque comme preuve d"un

savoir-faire. Un déni de service a quant à lui pour objet de rendre le site attaqué indisponible pour ses

utilisateurs légitimes. Dans les deux cas, l"impact sur le propriétaire du site est évidemment un déficit

d"image et, pour le cas d"un site servant de support à une activité lucrative, un manque à gagner.

Il ne faut toutefois pas négliger les scénarios d"attaques plus insidieux. Il est possible qu"un individu

malveillant se serve d"un site web comme une porte d"entrée vers le système d"information de l"héber-

geur ou, plus généralement, de l"entité à qui appartient le site. Par ailleurs, un site peut être utilisé

comme relai dans une attaque élaborée vers un système tiers ou comme dépôt de contenus illégaux,

ces situations étant susceptibles de mettre l"exploitant légitime du site en difficulté. Enfin, une attaque

sur un site peut aussi viser à tendre un piège aux clients habituels de ce site, qui sont souvent les

employés du propriétaire du site ou de ses partenaires. Ainsi, l"externalisation de l"hébergement d"un

site ne permet pas de transférer l"ensemble des risques d"intrusion au système d"information de l"hé-

bergeur. Toutes ces attaques ont en commun de rechercher, contrairement à celles évoquées plus haut,

une certaine discrétion et peuvent par conséquent rester insoupçonnées pendant de longues périodes.

La protection contre ces menaces passe à la fois par des mesures préventives et par des mécanismes

permettant de détecter les tentatives d"attaques.

2 PréventionCette section liste les principales mesures permettant de renforcer les protections d"un site web

contre les attaques. Elle n"est aucunement exhaustive mais permet de rappeler les principes classique-

ment admis comme devant présider à la mise en place d"un site web. Les recommandations doivent bien entendu être adaptées et déclinées en fonction du contexte d"emploi.

2.1 Infrastructure

Une première série de précautions peuvent être prises au niveau du système (matériel et logiciel)

hébergeant le service.

2.1.1 Architecture

Défense en profondeur

Le principe général de défense en profondeur s"applique évidemment aussi aux sites web. Il est

par conséquent conseillé de mettre en oeuvre plusieurs mesures de protection indépendantes face aux

menaces envisagées. Il est souvent beaucoup plus facile d"appliquer ce principe si le système à sécuriser

est découpé en éléments nettement séparés, aux interactions bien définies et possédant chacun leurs

propres mécanismes de sécurité.

Les architectures de type " n-tiers » par exemple se prêtent bien à une telle approche. Pour tirer

profit d"une telle architecture en terme de sécurité, il convient évidemment de ne pas concentrer toutesN

oDAT-NT-009/ANSSI/SDE/NP du 13 août 2013Page 3 sur22

les mesures de sécurité sur le " tiers » présentation. Au contraire, chaque composant doit assurer sa

propre protection.

Le découpage en composants isolés devrait idéalement ne pas être que conceptuel mais se refléter sur

l"organisation de l"architecture matérielle et logicielle de la solution d"hébergement. Selon le contexte

et les moyens disponibles, on peut par exemple dissocier les différents tiers sur des machines distinctes

en filtrant les échanges entre elles par des équipements de filtrage réseau ou plus simplement recourir

à un cloisonnement au sein d"une même machine en utilisant des processus distincts ou des solutions

de confinement telles que vServer, LXC, etc.R1L"architecture matérielle et logicielle du site web et de son infrastructure d"hébergement

doit respecter le principe de défense en profondeur.Un élément qui participe à la défense en profondeur est le filtrage par un pare-feu web (" WAF :

Web Application Firewall »). Une telle mesure ne permet en aucun cas de se dispenser de la sécurisation

du site mais apporte une barrière de protection supplémentaire.

Plusieurs implantations de pare-feu web existent : certains prennent la forme de composants réseau

pris sur étagère (COTS

1), d"autres sont des éléments logiciels à greffer2sur le serveur web ou sur

un serveur mandataire inverse (" reverse proxy ») placé devant le site web. La logique peut soit

être un modèle de sécurité négatif (liste noire), où seules les requêtes correspondant à une signature

d"attaque connue sont rejetées, soit un modèle de sécurité positif (liste blanche), où seules les requêtes

correspondant aux fonctionnement légitime de l"application sont acceptées. L"approche positive apporte

généralement une meilleure sécurité au prix d"une configuration plus complexe.

Composants logiciels

La plupart des sites web utilisent un grand nombre de composants logiciels : système d"exploitation

et serveur web mais aussi système de gestion de contenu et ses greffons, bibliothèques Java ou PHP ou

.NET, système de gestion de base de données, modules du serveur web, etc. De nombreuses attaques sur les sites web aboutissent en exploitant des vulnérabilités dans les

composants logiciels tiers et non pas dans le code spécifique au site. Un tel scénario est particulièrement

regrettable lorsque le logiciel exploité est présent mais non utilisé : il convient de réduire la surface

d"attaque en supprimant par exemple les greffons inutiles des systèmes de gestion de contenu.R2Les composants applicatifs employés doivent être limités au strict nécessaire.

R3Les composants applicatifs employés doivent être recensés et maintenus à jour.

Mécanismes d"administration

Les mécanismes d"administration des sites web sont par nature des éléments sensibles dont l"expo-

sition doit être limitée. Il convient donc de privilégier les protocoles sécurisés tels que SSH (notamment

SFTP).1. Commercial Off The Shelf.

2. On peut par exemple citer, pour les produits open-source, les modules Modsecurity (pour Apache, IIS et Nginx)

ou Naxsi (pour Nginx).N oDAT-NT-009/ANSSI/SDE/NP du 13 août 2013Page 4 sur22

Une pratique couramment observée mais qui doit être proscrite est l"alimentation du site web par

le protocole FTP. Il faut rappeler que FTP ne protège ni les mots de passe, ni le contenu transmis vis

à vis d"une écoute passive du réseau.

Dans le cas particulier d"une administration par une interface web, il faut privilégier le protocole

HTTPS qui protège le flux en confidentialité et en intégrité grâce au protocole TLS.Exemple

Dans le cas d"Apache, on peut aussi n"autoriser l"accès aux " Locations » correspondant à

l"administration que dans les virtualhosts où l"on a positionnéSSLEngineàon; c"est à dire

mettreOrder allow,denyetDeny from alldans les élémentsLocationdes virtualhosts non TLS.

On peut d"ailleurs définir un virtualhost en HTTPS uniquement à cet effet. Ainsi, même si la

partie publique du site peut ordinairement être consultée sans TLS, la partie administration sera sécurisée. Attention toutefois, si le site n"est pas exclusivement servi en HTTPS, il convient de prendre

garde à utiliser un cookie différent et sécurisé pour la gestion des sessions de la partie ad-

ministration. Sans cela, il existe un risque de vol de session lorsque l"administrateur navigue sur la partie du site en HTTP. Plus de détails sur ce sujet seront donnés en

2 .2.2

En outre, en utilisant la directiveSSLVerifyClient requireon peut forcer l"authentification

des clients sur ces " Locations », dès lors que l"on dispose d"une infrastructure de gestion de

clés publiques permettant de fournir des certificats aux administrateurs.R4L"administration d"un site web doit se faire via des protocoles sécurisés.

Lorsque c"est possible, il est préférable de restreindre l"accès à ces mécanismes aux seuls postes

d"administration autorisés. Cette restriction doit idéalement être appliquée par l"utilisation d"un réseau

d"administration connecté à une interface dédiée du serveur. Alternativement, il est possible de recourir

à un VPN IPsec pour créer virtuellement un réseau d"administration si les conditions d"hébergement

ne permettent pas de construire physiquement un tel réseau.

On pourraa minimamettre en place un filtrage réseau mais il faut garder à l"esprit que l"adresse

IP n"est pas un identifiant fiable : l"usurpation de l"adresse d"un administrateur est un scénario tout à

fait crédible. Une telle mesure constituera toutefois un premier rempart contre les attaques génériques.

Cette remarque s"applique également aux interfaces d"administration web. Dans ce cas, il convient

de redoubler de vigilance sur le contrôle d"accès et la traçabilité puisque l"un des premiers réflexes d"un

attaquant sera de rechercher de telles interfaces. Il peut être opportun d"exiger une authentification

mutuelle en utilisant des certificats TLS clients et serveur pour les pages d"administration.

Dans le cas où l"on est contraint de se contenter d"une authentification par mot de passe protégée

par TLS, les mots de passe doivent respecter les bonnes pratiques habituelles (voir les recommand ations sur le site de l"ANSSI

3) relatives à la complexité et à la fréquence de modification.3.www.ssi.gouv.fr/IMG/pdf/NP_MDP_NoteTech.pdf.N

oDAT-NT-009/ANSSI/SDE/NP du 13 août 2013Page 5 sur22

Exemple

Ainsi, lorsque le " manager » associé à Tomcat est utilisé, un certain nombre de mesures doivent être mises en oeuvre : supprimer les comp tespar défaut et gérer les utilisateur sd iposantde droits d"administra- tion (fichiertomcat-users.xml) en les affectant au groupe " manager » dédié. définir un connecteur sécurisé dans le server.xml, par exemple (cas avec authentification serveur uniquement) : forcer l"utili sationd"un connecteur sécurisé dans la section security-constraintdu fi- chierweb.xmlde l"application " manager » :

En complément, l"accès au manager (ou à toute application du même type) peut être filtré

en fonction de l"IP source de la requête, avec toutes les limitations associées à ce type de

filtrage, en mettant en oeuvre la valveorg.apache.catalina.valves.RemoteAddrValve(à

ajouter dans l"élémentContextde l"application considérée, se rapporter à la documentation

de la version de Tomcat utilisée pour plus de détail).R5L"accès aux mécanismes d"administration doit être restreint aux seuls postes d"administra-

tion autorisés.R6Les administrateurs doivent être authentifiés de manière sûre.

Disponibilité

La protection du site en disponibilité est un problème délicat. En effet, pour se protéger contre les

attaques les plus élémentaires, le maintien à jour des différents éléments logiciels et une bonne gestion

de la complexité des traitements pouvant être déclenchés par les requêtes utilisateurs peuvent suffire.

À ceci peut toutefois s"ajouter des mesures de haute disponibilité usuelles, classiquement par la mise

en oeuvre d"un système de répartition de charge.

Mais la protection contre les attaques plus élaborées telles que les dénis de service distribués

(" DDOS ») nécessite des mécanismes sophistiqués impliquant à la fois l"hébergeur et l"opérateur réseau.

Si l"on désire protéger un site donné contre de telles attaques, il est nécessaire de retenir des solutions

spécifiques permettant de bénéficier d"une protection au niveau de l"opérateur ou d"uncontent delivery

network (CDN). Certaines sociétés peuvent aussi offrir des prestations dédiées intégrant ces solutions.

Plus de détails sur le sujet sont donnés dans le document :http://www.certa.ssi.gouv.fr/site/

CERTA-2012-INF-001/index.html.

Parmi les mesures pouvant être mises en oeuvre à moindre frais, on peut citer le recours à des

outils tels quefail2banpour rejeter automatiquement les requêtes des clients ayant un comportement

suspect. Attention toutefois, ce mécanisme est à double tranchant : il peut lui même constituer un

levier pour un déni de service si un attaquant parvient à faire passer pour malveillante l"adresse du

relai sortant d"une entité regroupant de nombreux clients légitimes.N oDAT-NT-009/ANSSI/SDE/NP du 13 août 2013Page 6 sur22

2.1.2 Configuration

Un certain nombre de points doivent faire l"objet d"une attention particulière lors de la configuration

des systèmes d"exploitation et des services hébergeant le site web.

Moindre privilègeR7Le principe de moindre privilège doit être appliqué à l"ensemble des éléments du système.

Ainsi, il convient d"associer le serveur HTTP à un compte utilisateur non privilégié. En complément,

celui-ci peut être confiné au moyen de mécanismes tels quechroot,lxcou encoreapparmorpour les

environnements Linux.

Dans la même logique, les mécanismes de filtrage mis en place doivent privilégier un modèle " po-

sitif » où l"action par défaut est le rejet et où l"acception des requêtes constitue l"exception.Exemple

Un exemple classique de problème de sécurité introduit par un paradigme de règles négatives

est celui qui existait dans le paramétrage par défaut de certaines versions des branches 4.2 et 4.3 de JBoss. La configuration protégeant la console JMX était de la forme : An example security config that only allows users with the role JBossAdmin to access the HTML JMX console web application /* GET POST JBossAdmin En cherchant à lister explicitement les requêtes interdites, l"auteur de la configuration in- dique uniquement les méthodes GET et POST. Il était alors possible d"exécuter certaines opérations privilégiées au moyen d"autres commandes HTTP telles que HEAD ou PUT. Dans le cas d"espèce, il suffit de supprimer les élémentshttp-methodpour que la restriction s"applique à toutes les requêtes. L"erreur commise est toutefois compréhensible et doit in-

viter à redoubler de prudence sur le principe de moindre privilège dans les situations où le

comportement par défaut n"est pas l"interdiction.Il faut en particulier s"assurer que seuls les fichiers nécessaires peuvent être servis aux clients HTTP.

Une première précaution en ce sens est de chercher à maintenir hors de l"arborescence web les fichiers ne

devant pas être servis, tels que les fichiers d"installation, la documentation, les fichiers de configuration,N

oDAT-NT-009/ANSSI/SDE/NP du 13 août 2013Page 7 sur22

etc. En complément, au niveau système, l"utilisateur associé au serveur web ne doit pas avoir de droits

en lecture (ni en écriture!) sur les fichiers auxquels il n"a pas de raison d"accéder. On se servira pour cela

des ACL POSIX pour les systèmes UNIX ou des DACL Windows. Enfin, pour les cas où il est inévitable

que certains fichiers soient dans l"arborescence web et accessibles au serveur, il faudra s"assurer de bien

positionner les règles d"accès dans la configuration du serveur.Exemple Dans le cas d"Apache, plusieurs mécanismes permettent de configurer les droits d"accès. Il est possible de placer ce paramétrage dans la configuration générale du serveur ou directement dans l"arborescence au moyen de fichiers.htaccess.

Lorsque c"est possible dans le contexte d"emploi, il est préférable de retenir la première option

et de ne pas utiliser les fichiers.htaccess. Dans ce cas, pour éviter qu"un éventuel fichier .htaccessmalveillant ne soit interprété et permette de contourner la politique mise en place, il est important de positionner l"optionAllowOverrideàNonedans la configuration

d"Apache.R8Les fichiers pouvant être servis aux clients doivent être limités au strict nécessaire.

Par ailleurs, pour éviter que des éléments secrets, telles que les clés privées associées aux certificats,

ou des éléments sensibles, tels que les fichiers de configuration du serveur, soient consultés ou altérés par

des personnes ou des applications qui n"ont pas de raison légitime de le faire, on veillera à restreindre

autant que possible les droits d"accès à ces éléments. Il peut notamment être bénéfique de bien cloisonner

le rôle des différents exploitants pour confiner les effets de la compromission d"un compte.

Il est en outre conseillé de limiter les droits d"exécution de scripts CGI (ou équivalent) à un répertoire

bien identifié.Exemple Dans le cas d"Apache, ce répertoire est identifié grâce à la directiveScriptAlias. Aucun

autre répertoire ne doit avoir l"optionExecCGIvalidée.Enfin, un autre point important concernant le principe de moindre privilège est la gestion des droits

au niveau du système de gestion de bases de données (SGBD). Dans la plupart des cas, les utilisateurs

quotesdbs_dbs23.pdfusesText_29

[PDF] Les réseaux Peer-to-Peer

[PDF] L 'architecture postale - La Poste

[PDF] Partie 1 : Architecture et communications Client/Serveur - Univ Lyon 1

[PDF] Architecture Traditionnelle Méditerranéenne Méthode RehabiMed

[PDF] La fabrication de l architecture en Tunisie indépendante : une

[PDF] l 'architecture traditionnelle en tunisie : l 'habitat rural - RehabiMed

[PDF] Etude d une architecture IP intégrant un lien satellite - OATAO

[PDF] Les règles de classement et d 'archivage des documents d 'entreprise

[PDF] LES RECHERCHES CONCERNANT L ALGERIE - Archives nationales

[PDF] métiers de l 'audiovisuel et du cinéma information et communication

[PDF] LES RECHERCHES CONCERNANT L ALGERIE - Archives nationales

[PDF] Archives Nationales d 'Algérie - FranceArchives

[PDF] isdiah - UdG

[PDF] Les montagnes françaises 1) Les différents massifs montagneux

[PDF] Arduino Sample Code - Atlas Scientific