Headers HTTP Expect-CT et Feature-Policy

Discussion dans 'Administration d'un site Web' créé par WebRankInfo, 30 Janvier 2020.

  1. WebRankInfo
    WebRankInfo Admin
    Membre du personnel
    Inscrit:
    19 Avril 2002
    Messages:
    19 923
    J'aime reçus:
    485
    Un outil m'a dit qu'il me manquait les entêtes HTTP suivants :
    • Expect-CT
    • Feature-Policy
    Auriez-vous des explications quelque part sur la façon de les configurer ?

    idem pour les entêtes suivants, optionnels :
    • Access-Control-Allow-Origin
    • Public-Key-Pins
    • Public-Key-Pins-Report-Only
    merci d'avance !
     
  2. colonies
    colonies WRInaute impliqué
    Inscrit:
    10 Septembre 2006
    Messages:
    564
    J'aime reçus:
    70
    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.
     
  3. rick38
    rick38 WRInaute passionné
    Inscrit:
    23 Février 2013
    Messages:
    1 543
    J'aime reçus:
    210
    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).
     
  4. WebRankInfo
    WebRankInfo Admin
    Membre du personnel
    Inscrit:
    19 Avril 2002
    Messages:
    19 923
    J'aime reçus:
    485
    Merci bcp pour cette réponse. Il faudrait donc que je m'occupe des CSP : si tu as un tuto en français je suis preneur.
     
  5. colonies
    colonies WRInaute impliqué
    Inscrit:
    10 Septembre 2006
    Messages:
    564
    J'aime reçus:
    70
    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.
     
    WebRankInfo apprécie ceci.
  6. WebRankInfo
    WebRankInfo Admin
    Membre du personnel
    Inscrit:
    19 Avril 2002
    Messages:
    19 923
    J'aime reçus:
    485
Chargement...
Similar Threads - Headers Expect Feature Forum Date
Mauvais headers http Développement d'un site Web ou d'une appli mobile 12 Janvier 2015
Cannot send session cache limiter - headers already sent en php5 Développement d'un site Web ou d'une appli mobile 14 Mars 2013
Add Expires headers Développement d'un site Web ou d'une appli mobile 16 Décembre 2011
Envoyer un mail() sur hotmail. Quels headers ? Développement d'un site Web ou d'une appli mobile 30 Juillet 2011
Redirection & headers HTTP site e-commerce Développement d'un site Web ou d'une appli mobile 31 Mai 2011
Expires headers Débuter en référencement 25 Avril 2011
Problème Expire headers avec mod_expires URL Rewriting et .htaccess 9 Décembre 2010
Performance "Add Expires headers" Développement d'un site Web ou d'une appli mobile 24 Novembre 2010
Headers dans le contenu du mail sous Thunderbird Développement d'un site Web ou d'une appli mobile 2 Novembre 2010
envoi de headers après mysql_query() Développement d'un site Web ou d'une appli mobile 23 Octobre 2010