Headers HTTP Expect-CT et Feature-Policy

Alors les deux premiers, franchement, on s'en fout. Expect-CT en particulier.
À la limite, sur Feature policy : tu peux mettre un peu ce que tu veux. Par exemple :
header("Feature-Policy: geolocation 'none'; microphone 'none'; payment 'none'");
C'est le même genre de syntaxe que les CSP :
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy

Le truc, c'est : à quoi ça te sert vraiment ?
Ces choses là ne servent que pour limiter les dégâts si tu donnes un accès illimité à des tiers. Par exemple, si tu insères un script sur lequel tu n'as aucun contrôle : tu peux indiquer au préalable qu'il n'aura pas le droit d'accéder à la géolocalisation, au micro, etc.
C'est une approche de la sécurité assez ridicule, à vrai dire.

Le reste, c'est un peu pareil.

Si tu veux passer des tests d'outils, tu peux t'amuser à te taper les specs et essayer de rattraper une mauvaise conception, mais le vrai truc qui compte, c'est de tout blinder avec des CSP ultra restrictives et de n'accepter aucune ressource externe. Mais ça, c'est faisable seulement pour des sites qui peuvent vivre en autarcie complète.
Le problème c'est qu'il y a toujours un département marketing qui t'impose d'intégrer des trucs de gens qui font n'imp, ou une DSI de rigolos qui ne connaissent pas leur métier et qui veulent ajouter des outils externes de monitoring.

Un peu aigri, moi ? Noooon, du tout.

Tous les trucs que tu mentionnes sont développés par des gens qui connaissent vraiment les risques, proposent des choses, mais qui sont irréalistes dans des sociétés où ça ne sont pas les techniciens qui font les choix importants.

Tu peux trouver les infos que tu veux en tapant tout ce sur quoi que tu t'interroges en recherchant chaque terme et en ajoutant "MDN" derrière : Mozilla a des docs pour tout. Mais si tu les implémentes juste pour passer des tests, ça va sûrement casser beaucoup de choses.

Juste pour mettre les choses en perspective : le DEA peut annoncer sur le site du ministère des armées français qu'on a déclaré la guerre à la Chine, par exemple. Sans problème. Voilà le niveau de sécurisation dans lequel on est, globalement.

 

Oui, si c'est pour mettre les valeurs par défaut, autant ne pas mettre et ne pas alourdir le header (c'est toujours quelques octets de gagnés à chaque appel de ressource).

 

Tu as MDN : https://developer.mozilla.org/fr/docs/Web/HTTP/CSP
et https://developer.mozilla.org/fr/docs/Web/HTTP/Headers/Content-Security-Policy
mais il y a beaucoup de choses non traduites : presque tout dans les directives du menu de gauche est rouge alors que tout est détaillé en version anglaise.
En anglais (au cas où) : https://www.html5rocks.com/en/tutorials/security/content-security-policy/


L'idée des CSP, c'est que plutôt que d'avoir un navigateur qui peut interpréter du code provenant de n'importe où, tu peux le restreindre à ce qui est prévu. Dans l'idéal, tu commences par tout bloquer, et tu ouvres au fur et à mesure de tes besoins.

Tu peux donc indiquer au navigateur que tu veux qu'il n'exécute pas de javascript servi par une autre URL que ton site, et pas de script inline, sauf éventuellement ceux marqués d'un identifiant unique (nonce), ou bien dont le hash est la valeur indiquée, ou bien faire entièrement confiance à un domaine spécifique...

Idem pour les CSS, les iframes, etc.

Bien entendu, ça ne sert que si la page peut afficher du contenu envoyé par les utilisateurs. Si tu as un simple site statique qui n'appelle aucune ressource externe, tu peux complètement t'en passer (mais ce genre de site est très rare, il faut bien le dire).

Globalement, ça permet principalement de forcer une discipline de sécurité, et d'éviter les failles de sécurité les plus communes.

Par exemple, un développeur travaillant sur un site permet à l'utilisateur de saisir ce qu'il veut et l'affiche tel quel (un forum, mettons, ou des commentaires, avis clients...). C'est un problème classique qui permet à une personne malveillante d'injecter un script.

Si tu as mis en place une CSP qui dit que le javascript doit obligatoirement être dans un fichier externe sur ton serveur, ça complique nettement les attaques : l'attaquant ne peut plus faire exécuter du script inséré sur la page même. Il peut encore insérer un <script src> s'il trouve le moyen d'héberger le script malicieux par le site attaqué.

Mais il est possible d'empêcher cet autre moyen d'attaque en implémentant en plus un nonce (qui est envoyé avec la page et qui change à chaque fois). Par exemple, tu génères l'identifiant 7iBRvIfLCIOy6shyhga2YHVeANg pour la page.

Ton header CSP contient :
script-src 'nonce-7iBRvIfLCIOy6shyhga2YHVeANg'

et toutes tes balises script seront de la forme :
<script nonce="7iBRvIfLCIOy6shyhga2YHVeANg">

Si une balise script n'a pas le bon nonce, le script ne sera pas exécuté. Comme il change à chaque fois, il n'est plus possible d'insérer un script malicieux en se contentant d'ajouter du contenu non filtré (ou plutôt, il ne sera pas exécuté).

Voilà pour un exemple simple de restriction par les CSP, et en quoi ça aide à relever le niveau de sécurité d'un site.