De nos jours, il est nécessaire de sécuriser au maximum ses sites Internet ou ses utilisateurs afin qu’ils ne soient pas piratés. En effet, avec l’explosion d’Internet et l’ouverture des SI vers le monde extérieur au travers des différents extranets, la surface d’attaque est de plus en plus grande pour des individus malveillants. Afin de mettre toutes les chances de son côté, il est nécessaire de connaitre quelques en-têtes http qui permettent de rajouter une couche de protection significative.

Avertissement préliminaire

Les en-têtes qui seront décrits par la suite ne fonctionnent pas sur toutes les versions des navigateurs. Par conséquent, il ne faut pas s’appuyer uniquement sur ceux-ci. Il ne s’agit que d’une couche supplémentaire de protection et il convient d’appliquer les contrôles habituels comme la validation des entrées/sorties, le contrôle des droits de l’utilisateur, etc.

X-FRAME-OPTIONS

L’en-tête HTTP X-Frame-Options permet d’indiquer aux navigateurs supportant cette extension, d’afficher ou non une page dans un champ HTML ‘<frame>’, ‘<iframe>’ ou ‘<object>’.

Les sites Internet peuvent utiliser cet en-tête afin de se protéger des attaques « ClickJacking », en s’assurant que leurs contenus ne soient pas embarqués dans d’autres sites.

Utilisation du X-Frame-Options

Il est possible d’utiliser 3 valeurs de paramétrage :

  • DENY : La page ne pourra pas être affichée dans une balise <(i)frame>
  • SAMEORIGIN : La page ne pourra être affichée dans une balise <(i)frame>que si la page provient du même domaine et du même port (SOP : Same Origin Policy )
  • ALLOW-FROM uri : La page ne pourra être affichée dans une balise <(i)frame> que si elle provient de l’origine spécifiée

Si nous spécifions DENY, il sera impossible de faire des frames dans le site Internet, même avec des pages internes. Si vous souhaitez intégrer des frames de votre site (même domaine), il faudra utiliser SAMEORIGIN mais il faudra faire attention que les pages à inclure soient présentes sur le même protocole (par exemple il n’est pas possible d’inclure la page http://www.lexsi.fr/page1.html depuis la page https://www.lexsi.fr/page2.html). Enfin, pour intégrer des pages externes, il faudra utiliser ALLOW-FROM et spécifier le domaine ou la page.

Il est possible de configurer les serveurs afin qu’ils ajoutent automatiquement cet en-tête.

Attention : Il est à prohiber l’utilisation du joker (*) pour l’en-tête ALLOW-FROM dès lors qu’un site possède une partie authentifiée.

Configuration Apache

Afin de configurer Apache pour qu’il utilise l’en-tête X-Frame-Options, il suffit d’ajouter dans le fichier de configuration les lignes suivantes :

Configuration Apache Lexsi

Configuration Apache

Configuration IIS

Afin de configurer IIS pour qu’il utilise l’en-tête X-Frame-Options, il suffit d’ajouter dans le fichier web.config les lignes suivantes :

Configuration IIS Lexsi

Configuration IIS

Content-Security-Policy

L’en-tête Content-Security-Policy permet de restreindre l’accès à une ressource (un script JavaScript, une feuille de style, etc.) dans une page web à certains sites autorisés. Cela permet par exemple d‘atténuer l’impact d’une éventuelle faille XSS en autorisant le chargement de script JavaScript que depuis le domaine du site Internet.

Si le navigateur du client ne reconnaît pas cet en-tête, ce dernier l’ignore complètement, et le fonctionnement ne change pas.

Il existe différents nommages de cet en-tête, suivant l’époque où il a été implémenté dans les navigateurs :

  • Content-Security-Policy : Définit par le W3C et utilisé par Chrome 25 et supérieur, FireFox 23 et supérieur, Opéra 19 et supérieur.
  • X-Content-Security-Policy : Utilisé par Firefox jusqu’à la version 23 et Internet Explorer 10 (avec une implémentation partielle).
  • X-WebKit-CSP : Utilisé par Chrome jusqu’à la version 25.

Les différentes directives utilisables sont :

  • default-src : Définit la politique pour les types ressources ou une directive spécifique n’est pas définie
  • script-src : Définit quels scripts peuvent être exécutés
  • object-src : Définit d’où la ressource peut charger des plugins
  • style-src : Définit les feuilles de styles utilisables
  • img-src : Définit d’où la ressource peut utiliser les images
  • media-src : Définit d’où la ressource peut utiliser les vidéos et les sons
  • frame-src : Définit d’où la ressource peut embarquer des frames
  • font-src : Définit d’où la ressource peut utiliser des polices de caractères
  • connect-src : Définit les URI que la ressource peut charger via scripting
  • form-action : Définit les URI que la ressource peut utiliser comme action d’un élément de formulaire
  • sandbox : Spécifie la politique de bac-à-sable HTML
  • script-nonce : Définit l’exécution de script en exigeant la présence d’un nonce
  • plugin-types : Définit une liste de plugins qui peuvent être invoqués
  • reflected-xss : Permet d’activer ou désactiver les heuristiques des navigateurs pour la protection XSS (identique à l’en-tête X-XSS-Protection)
  • report-uri : Spécifie une URI vers laquelle le navigateur enverra un rapport en cas de violation de politique

Exemple d’utilisation

Exemple d’utilisation de Content-Security-Policy

Exemple d’utilisation de Content-Security-Policy

Dans notre exemple, la première partie indique que seules les ressources (javascript, image, css, etc.) sur le même domaine (self) peuvent être utilisées. La deuxième partie indique au navigateur compatible d’activer son filtre XSS et de bloquer l’attaque en cas de détection (ce fonctionnement est le même que l’en-tête HTTP X-XSS-Protection : 1; mode=block).

HTTP Strict Transport Security

L’en-tête HTTP Strict Transport Security (HSTS) est un mécanisme de sécurité permettant à un serveur Web d’indiquer à un navigateur compatible d’utiliser une connexion sécurisée (HTTPS).

Lorsque l’en-tête HSTS est activé, le navigateur compatible agit de la façon suivante :

  • Il remplace tous les liens non sécurisés par des liens sécurisés (i.e. il remplace HTTP par HTTPS),
  • Si une connexion sécurisée ne peut être effectuée (Certificat auto-signé par exemple), le navigateur affiche un message d’erreur et interdit l’accès au site (il est impossible pour l’utilisateur d’accepter un certificat non valide).

Tous les navigateurs ne sont pas compatibles avec cet en-tête. Seuls les suivants le sont :

  • Google Chrome et Chromium depuis la version 4.0.211.0
  • Firefox depuis la version 4.0
  • Opera depuis la version 12
  • Safari sous OS X Mavericks
  • Spartan et Internet Explorer 11

Note : L’extension pour Chrome, Firefox et Opera « HTTPS Everywhere » généralise le concept de HSTS.

L’en-tête HSTS accepte différentes directives :

  • max-age : nombre de secondes, après la réception de l’en-tête, durant lesquelles le navigateur adoptera la politique
  • includeSubDomains : indique qu’il faut appliquer la politique aussi sur les sous domaines

La directive max-age est obligatoire alors que la directive includeSubDomains ne l’est pas.

Il convient de mettre une durée aussi longue que possible afin de s’assurer que la durée de navigation de l’utilisateur soit inférieure à ce temps limite. Par exemple, si vous spécifiez 86400 secondes, l’utilisateur peut naviguer et être protéger sur le site pendant 24 heures consécutives.

Note : L’en-tête Strict-Transport-Security est ignoré par le navigateur si on accède à votre site en utilisant le protocole HTTP ; en effet, un attaquant malveillant peut intercepter les connexions via HTTP et injecter un autre en-tête ou le supprimer.

Quand on accède à votre site via HTTPS sans erreur de certificat, le navigateur sait que le site est compatible HTTPS et respectera l’en-tête Strict-Transport-Security.

Exemple d’utilisation

Exemple utilisation Strict-Transport-Security Lexsi

Exemple utilisation Strict-Transport-Security

Configuration Apache

Configuration Apache pour Strict-Transport-Security Lexsi

Configuration Apache pour Strict-Transport-Security

Configuration IIS

Le module STSModule peut être installé afin d’ajouter les en-têtes HSTS.

IIS _Module STS Lexsi

IIS : Module STS

Il suffit après de le configurer ainsi :

IIS _Configuration du module STS

IIS : Configuration du module STS

Implémentation JSP

Implémentation JSP du Strict-Transport-Security

Implémentation JSP du Strict-Transport-Security

X-Content-Type-Options

Cet en-tête permet de faire une vérification stricte des types Mime. Elle n’accepte qu’une seule directive : nosniff.

Entete X-Content-Type-Options

En-tete X-Content-Type-Options

Si cet en-tête est spécifié, le navigateur compatible (Google Chrome ou Internet Explorer) ne chargera, par exemple, que les feuilles de style dont le type Mime est « text/css ».

Cela permet de se protéger des attaques de type « drive-by-download ». Si cet en-tête n’est pas spécifié, le navigateur va essayer de déterminer le type de données en analysant le contenu de la ressource demandée.

En ce qui concerne une référence à un script, le type Mime doit être un de ceux-ci :

  • application/ecmascript
  • application/javascript
  • application/x-javascript
  • text/ecmascript
  • text/javascript
  • text/jscript
  • text/x-javascript
  • text/vbs
  • text/vbscript

X-XSS-Protection

Cet en-tête permet d’activer les filtres anti-xss incorporés dans certains navigateurs. Seuls Internet Explorer, Google Chrome et Safari (WebKit) supportent cet en-tête.

Les réglages suivants sont valides :

  • 0 : Désactive les protections XSS du navigateur
  • 1 : Active les protections XSS du navigateur
  • 1; mode=block : Active la protection XSS du navigateur et bloque la réponse au lieu de nettoyer les valeurs
  • 1; report=http://site.com/report : Directive spécifique à Chrome et WebKit lui indiquant d’envoyer, via une requête POST, l’attaque XSS potentielle à l’url spécifiée au format JSON.

Exemple d’utilisation

Exemple d’utilisation de X-XSS-PROTECTION

Exemple d’utilisation de X-XSS-PROTECTION

Exemple de désactivation de la protection

Figure 1 Code source vulnérable avec désactivation de la protection

Figure 1 Code source vulnérable avec désactivation de la protection

Figure 2 Résultat de la désactivation de la protection anti-XSS

Figure 2 Résultat de la désactivation de la protection anti-XSS

Nous pouvons donc voir qu’effectivement la protection apportée par Chrome n’est plus active car le XSS est bien exploité.

Exemple d’activation de la protection avec envoi du rapport

Figure 3 Code source vulnérable avec activation de la protection et envoi d'un rapport

Figure 3 Code source vulnérable avec activation de la protection et envoi d’un rapport

Figure 4 Résultat de l'envoi du rapport suite à détection XSS

Figure 4 Résultat de l’envoi du rapport suite à détection XSS

Conclusion

Grâce à tous ces en-têtes, il est donc possible d’ajouter une couche supplémentaire de sécurité et il serait déraisonnable de s’en priver. En effet, plus il y a de barrières entre un attaquant et vous, mieux c’est.

Bien sûr cela ne fonctionne que sur les navigateurs de dernières générations pour certains en-têtes et uniquement si la couche de transport est sécurisée (https). Dans le cas contraire, un attaquant pouvant se mettre en position de Man-In-The-Middle, supprimera les différents en-têtes. Il ne faut donc pas reposer la sécurité de son site uniquement sur ces en-têtes qui sont en effet un outil de plus à utiliser.