Plugin HTTPHeader

[woluweb]

Salut pmleconte ,

Je viens d'ajouter ton lien sur le site du JoomlaDay :

https://www.joomladay.fr/2019/programme/conferences/securisation-des-sites-par-les-headers-http

Si tu as encore d'autres choses à ajouter ( p ex concernant ton autre conf), n'hésite pas à me contacter en direct.

[pmleconte]

Salut pmleconte ,

Je viens d'ajouter ton lien sur le site du JoomlaDay :

https://www.joomladay.fr/2019/programme/conferences/securisation-des-sites-par-les-headers-http

Si tu as encore d'autres choses à ajouter ( p ex concernant ton autre conf), n'hésite pas à me contacter en direct.

Merci.

Juste pour info, il y a une nouvelle version du plugin httpheader (version 1.0.6) qui écrit désormais les informations saisies dans le htaccess ou le web.config : https://github.com/zero-24/plg_syste...ases/tag/1.0.6.

En discutant avec diverses personnes à propos du bien fondé d'un plugin pour protéger le site, il y avait effectivement une porte ouverte qui vient d'être fermée .

Hello,
pour info.
Il apparait que ce plugin a été intégré dans joomla 4.
Il existe même une doc :

J4.x:Http Header Management - Joomla! Documentation

https://docs.joomla.org/J4.x:Http_Header_Management

Au niveau de Joomla 4.0, un composant sera ajouté au plugin afin de suivre les logs

Pascal

[Eddy.vh]

Jusqu'à la version 4 et la migration de Flo, elle aura besoin d'explications. J'ai promis des screenshots, les voici.

1. Le premier est le paramétrage des headers http le + permet l'ajout, comme on le voit dans la capture d'autres en-têtes. J'ai personnellement ajouté le Feature-Policy
2. Le second est tout simple…
3. Le troisième permet la gestion des CSP.
   1. La première CSP à ajouter est celle par défaut ou on limite à self
   2. À partir de là, on aura besoin de la console pour contrôler toutes les pages su site et ajouter au fur et à mesure les CSP nécessaires.
   3. On trouvera assez rapidement que les images ont besoin d'une CSP (img-src), on ajouter alors une option à l'aide du + et on inscrit img-src en tant que Directive. On ajoute les valeurs autorisées - 'self' qui autorise nos images puis on ajoutera les sites desquels on autorise l'affichage des images sur nos pages, p.ex. www.gravatar.com (sans le http(s)://) si on utilise un système de commentaires affichant des gravatars. Etc.
   4. On continue de scruter les pages du site et on intervient sur chacune des erreurs affichée pour la corriger. La console indique dans quel type de directive il faut intervenir et indique le lien ou les options à ajouter. style-src pour l'utilisation des styles de fontes Google, etc.
   5. Dans certains cas de directives et parce que 'on ne peut faire autrement, il faudra ajouter 'unsafe-inline' afin d'autoriser le contenu inline de type scripts, styles…

Après avoir ajouté l'une ou l'autre directive, on comprend très rapidement comment il faut les intégrer. Retester chaque page du site pour être sûr de ne rien oublier et y intervenir tant que des erreurs se manifestent dans la console.

Bonne chance.

[FlodAriege]

Waouh !
Merci Christophe Eddy.vh pmleconte ghazal pour vos réponses !


Donc voilà, je me suis jetée à l'eau, ai installé le plugin et activé les 3 options "faciles" du 1er onglet.
Mon site est repassé en B (je vous rappelle que je partais du F quand même...)

Au passage, j'ai supprimé la directive que j'avais récemment mise en place dans mon .htaccess pour le X-Content-Type-Options, car le scan ne le voyait tout simplement pas.
Je l'avais pourtant copié depuis les messages post installation, et collé à l'endroit précis où l’interface me recommandait de le faire.
Maintenant que cette sécurité est gérée par le plugin, ce critère est passé au vert dans le scan.

Bien.

Onglet suivant : HSTS
a) Est-ce que je cours un risque particulier (genre irréversible sans devoir aller trifouiller dans la BDD) en activant cette option ?
b) dois-je activer le préchargement ?

Maintenant, il faut que je me penche sur l'onglet CSP et là je sens bien que c'est plus compliqué qu'appuyer sur un bouton Activé...
J'ai donc commencé par inspecter tous les cripts qui s'affichent via la console / network, et ai remarqué que certains étaient logés sur mon domaine, d'autres sur google, addthis etc.
J'imagine que je vais devoir essayer d'écrire quelque chose comme :

script-src 'self' www.google.com www.googletagmanager.com www.gstatic.com www.google-analytics.com s7.addthis.com m.addthisedge.com m.addthis.com api-public.addthis.com graph.facebook.com

... ou bien puis-je faire l'économie des sous-domaines en simplifiant en :

script-src 'self' www.google.com www.googletagmanager.com www.gstatic.com www.google-analytics.com addthis.com m.addthisedge.com facebook.com

??

Et puis surtout, comment est-ce qu'on saisit ça dans l'outil du plugin ?
Comme ça, je dirais qu'il faut que je saisisse :
- Directive de la politique : script-src
- Valeur : (liste des URL ci-dessus)
- Client : Les deux

Flo

[jfque]

Pour HSTS, il y a plusieurs articles sur le sujet, dont celui-ci : https://kinsta.com/fr/base-de-connai...port-security/ (c'est au départ pour Wordpress, mais ne soyons pas sectaire).
Quand on préchargement, c'est optionnel mais il y a quand même une mise en garde (en plus des conditions à satisfaire pour y accéder), c'est qu'il faut être sûr de ne JAMAIS revenir en arrière, donc pare exemple être sûr de toujours renouveler à temps son certificat SSL, ce qui peut parfois poser des problèmes avec des certificats Let's Encrypt qui ne sont valables que 3 mois, avec un renouvellement automatique ... en principe, sauf erreur de configuration, bug, ... Je pense que c'est à préférer avec un certificat dont on contrôle le renouvellement (SSL Standard ou version PRO et Extended pour les sociétés).

A part ça, pour limiter les entrées dans la CSP quand c'est possible, vous pouvez utiliser la notation "*.domaine.tld" pour couvrir "domaine.tld", "www.domaine.tld", "blog.domaine.tld", "m.domaine.tld", ...

[FlodAriege]

Merci jfque: HSTS activé, et grade A obtenu.
Apparemment jusqu'ici tout fonctionne.

J'ai un autre problème mais qui n'a rien à voir, je vais ouvrir un post (une histoire de CDN chez 1&1)

Bonne soirée !

[GraphiqueDesign]

Il me semble que x-frame-options est à présent par défaut dans le .htaccess de Joomla, attention au double emploi, le cas échéant.

[Eddy.vh]

Bonjour.

C'est le X-Content-Type-Options qui se trouve désormais dans les nouvelles installations Joomla!.

[Eddy.vh]

PS.

J'ai mis en œuvre l'activation de la nouvelle fonction d'inscription des en-têtes dans le .htaccess et ai testé le site. Cela provoque des doublons si on laisse le tout actif dans le plugin.

Ce que j'ai fait pour remettre le tout correctement :

J'ai activé la fonction d'inscription, ai validé, ai vérifié mon htaccess, les en-têtes s'y trouvent bien.
J'ai ensuite désactivé la fonction et désactivé tout sauf les CSP pour retrouver une configuration sans doublons.

Si daneel pouvait confirmer que ce soit la chose à faire. Merci infiniment.

[pmleconte]

PS.

J'ai mis en œuvre l'activation de la nouvelle fonction d'inscription des en-tête dans le .htaccess et ai testé le site. Cela provoque des doublons si on laisse le tout actif dans le plugin.

Ce que j'ai fait pour remettre le tout correctement :

Jj'ai activé la fonction d'inscription, ai validé, ai vérifié mon htaccess, les entête s'y trouvent bien.
J'ai ensuite désactivé la fonction et désatvié tout sauf les CSP pour retrouver une configuration sans doublons.

Si daneel pouvait confirmer que ce soit la chose à faire. Merci infiniment.

Bonjour Eddy,

Au niveau des doublons, la version 3.9.5 corrige certains points, mais, j'ai proposé une modification à Frantz https://github.com/zero-24/plg_syste...header/pull/14 car le site securityheaders.com trouve les headers déclarés 2 fois, sans toutefois modifié la note du site.

J'ai fait une issue https://github.com/zero-24/plg_syste...ader/issues/15 car, si on change d'avis (typiquement français cette attitude...), les informations restent dans le fichier htaccess et sont en doublon avec celles générées à la création de la page par le plugin, pouvant créer des incohérences. De mon côté, j'ai corrigé la partie htaccess, mais, je n'ai pas pu le faire pour le fichier web.config (je n'ai pas d'environnement pour le valider ).

Pascal

[daneel]

Si daneel pouvait confirmer que ce soit la chose à faire. Merci infiniment.

oui je plussoie
Mais je suis également curieux de la réponse qui sera donnée à la proposition de Pascal.

Dans tous les cas, merci pour vos retours !

[Eddy.vh]

Daneel.

Merci pour la confirmation. Bonne fin de semaine à tous.

[FlodAriege]

Bonjour,

Pourriez-vous SVP m'expliquer deux choses :

1/ afin de vérifier que je n'avais pas de doublon sur X-Content-Type-Options (je pensais bien avoir commenté les lignes que j'avais insérées à ce sujet sur conseils des message post-installation, mais je voulais m'en assurer), j'ai comparé mon htaccess avant / après activation du plugin.
et...
zéro différence.
pourtant le scan de securityheaders.com détecte bien les sécurités récemment mises en place.
Où le plugin implémente-t-il ces sécurités si ce n'est dans le htaccess ??

2/ je voudrais m'assurer de ne pas faire de bêtise avec les CSP
j'envisage donc de commencer par des report-only, mais une fois que j'ai dit ça, j'ai dit à peu près tout ce que je sais... c'est-à-dire pas grand chose.
j'ai déjà relevé les scripts qui s'exécutent sur mon site (source externe) afin de les autoriser, mais je vois bien que les CSP ne portent pas que sur le JS.
comment savoir quoi mettre dans les autres "valeurs" : style, frame, etc etc
Est-ce que "Report URI" va me faire un genre de liste une fois que j'aurais saisi mes CSP ?

(à ce propos, mille merci pour les tips de fin d'article sur https://www.conseilgouz.com/espace-t...19-httpheaders ça donne déjà une première idée de ce qu'il faut faire !)

Merci encore.

[Eddy.vh]

Si le plugin n'est pas configuré pour inscrire dans le htaccess, il me semble que Joomla va charger les options du plugin dans son PHP comme il appèle les fonctions de n'importe quel plugin..
Si l'inscription dans le htaccess est activée, il inscrit alors les entêtes tout en fin de fichier.

Pour les CSP, après avoir appliqué la première, default-src à 'self', tout est bloqué hormis ce qui est hébergé sur ton domaine. Le test sur la console te dit alors tout sur ce qui est à ajouter.
p.ex. Si tu affiches des images externes à ton site, tu devras alors ajouter une CSP img-src avec l'incontournable 'self' puis les url's des sites autorisés à afficher leurs images sur ton site (partenaires éventuels, Google pour une map, etc.)

La console t'indique ce qui est à créer (nouvelle règle) ou ajouter (à une règle déjà créée).
C'est plus difficile à expliquer qu'à mettre en œuvre. J'appréhendais aussi le paramétrage de ces CSP et finalement, une fois que j'avais instauré la première, le reste à suivi sans aucune difficulté.

Pour te faire la main, crée une copie de ton site en sous-domaine et prends tes marques là-dessus.
Si la console te parle de ressources inline, il faudra probablement ajouter 'unsafe-inline' à la règle ciblée dans les directives ("style" et "scripts"), si elle te parle d'eval, il faudra peut-être ajouter un "unsafe-eval" dans les scripts, etc.

Teste bien toutes les pages de ton site, il se peut qu'une page ne réclame rien et que la suivante se comporta autrement selon son contenu et les autorisations.

Allez, y plus qu'à…

[FlodAriege]

Bonsoir Eddy.vh
Bonsoir tout le monde,

Ca y est, je me suis lancée sur les CSP !
Avec la console de Chrome + les rapports générés sur Report URI, j'arrive, je crois, à comprendre quoi mettre dans les directives.

Il y a juste un truc qui me chiffonne : les unsafe-inline qu'il faudrait remplacer par des hash 'sha256-xxxxxxxxxxxxxxxxxx'.
J'ai analysé les données de la console, j'ai :
- plusieurs centaines de sha256 différents sur la directive style-src)
- et un nombre inconnu (une 15aine selon Report URI mais j'ai atteint la limite du nombre de tests alors...) sur la directive script-src...

Sauf à les saisir tous (faisable avec quelques traitements Excel / Notepad, je pense), la seule option serait de rester sur un unsafe-inline.
D'autant que vu le très grand nombre de ces hash, je me dis qu'il peut en naître de nouveaux à tout instant, et ne jamais tout couvrir à 100%...
Qu'en penses-tu ?

Est-ce que ce nombre te parait inquiétant ou pas ?

Je lis sur le blog Dareboost :

plus d’unsafe-inline (donc plus de JS inline non-protégé par hash/nonce dans vos pages). En clair, soit votre JS inline est protégé par un hash/nonce, soit vous le stockez dans des fichiers externes servis sur des origines approuvées.

Est-ce à dire que ces hash peuvent être intégrés dès la création du JS inline ?
Et puis c'est quoi, d'abord, un JS inline ?? Parce que j'ai beau scruter ma console, je n'arrive pas à comprendre ce qui insère ces scripts...

Bonne nuit