Plugin HTTPHeader

[pmleconte]

Bonjour,

Sur la plupart des templates, modules, plugins, extensions, dans le code php, on a des insertions de scripts javascript ou de css.

Par exemple, j'utilise des templates Joomspirit et j'ai, dans le fichier index.php des lignes

<style type="text/css">
.... du CSS
</style>

Ce type de lignes passera en CSP avec une commande

style-src unsafe-inline

De même, dans la plupart des modules, on retrouve des lignes <script type="text/javascript">... du code javascript ...</script> qui seront résolus par la commande script-src unsafe-inline

Cela ne fait pas perdre le A au niveau du securityheaders.com mais, la ligne script-src unsafe-inline fait perdre le + du A+.

Pour éviter cela, il faut
- soit ajouter dans le plugin httpheaders des commandes SHA-256 pour chaque script signalé dans la console, mais, à chaque changement de script (mise à jour d'un module par exemple, voire même d'un paramètre), il faut vérifier que cela fonctionne toujours,
- soit demander au développeur des modules/extensions/templates de faire la modification pour être conforme au CSP (j'ai fait la modification sur la plupart de mes modules et c'est un peu long, mais nécessaire) voir https://www.conseilgouz.com/espace-t...-days-2018-csp
- soit vivre avec le unsafe-line.

Pour info, je ne sais pas si tu as lu l'article https://www.joomla.fr/actualites/joo...ogle-a-chicago où il est question de "projets favorable au CSP pour prévenir les attaques XSS".

Bon dimanche,

Pascal

[Eddy.vh]

Bonjour.
Pascal a tout dit.
Bon dimanche.

[FlodAriege]

Bonjour,

Sur la plupart des templates, modules, plugins, extensions, dans le code php, on a des insertions de scripts javascript ou de css.

En effet, quand je scrute la console, je vois, pour les lignes JS dont l'initiateur est mon domaine, des lignes appelant des plugins et des modules : GDPR, JQuery, Sigplus, MaximenuCK, et divers modules présents sur la page... Je comprends mieux, en te lisant, la corrélation, car au départ je me disais "comment peut-il y avoir du script inline alors que je n'écris jamais le moindre script moi-même ??

Ce type de lignes passera en CSP avec une commande

style-src unsafe-inline

C'est ce que je me suis résolue à faire, pas le choix car même en identifiant tous les sha256 de cette page, rien ne me dit qu'il n'y en a pas autant, et différents de ceux-ci, sur les 400 et quelques autres pages du site...

Cela ne fait pas perdre le A au niveau du securityheaders.com mais, la ligne script-src unsafe-inline fait perdre le + du A+.

Au-delà du seul + que cela fait perdre dans ce scan, c'est surtout le warning :

This policy contains 'unsafe-inline' which is dangerous in the script-src directive. This policy contains 'unsafe-eval' which is dangerous in the script-src directive.

qui me dérange, car au final je ne sais pas quel niveau de risque cela laisse sur le site.

Tu noteras au passage que j'ai également dû laisser des unsafe-eval, ne parvenant pas non plus à être sure que j'identifierais TOUS les sha256 nécessaires à éviter ce contournement...

Pour éviter cela, il faut
- soit ajouter dans le plugin httpheaders des commandes SHA-256 pour chaque script signalé dans la console, mais, à chaque changement de script (mise à jour d'un module par exemple, voire même d'un paramètre), il faut vérifier que cela fonctionne toujours,

C'est bien le pire : même en imaginant que j'arrive à extraire TOUS les sha256 nécessaires aujourd'hui sur TOUTES les pages du site, rien ne me dit qu'à chaque mise à jour ou changement sur le site il ne me faille pas refaire ce travail de titan...



En tout cas, merci pour tes explications.
Je décide d'en rester là pour l'instant, et me contenterai du A obtenu (déjà très bien sachant que j'étais en F il y a une semaine...) en attendant que les éditeurs de plugins / modules / templates se mettent à produire des contenus plus "CSP friendly".

Bon dimanche.

[ghazal]

pmleconte

- soit ajouter dans le plugin httpheaders des commandes SHA-256 pour chaque script signalé dans la console, mais, à chaque changement de script (mise à jour d'un module par exemple, voire même d'un paramètre), il faut vérifier que cela fonctionne toujours,

Re : SHA-256
Est-ce ce dont tu parles - la série de chiffres après jquery.min.js ?
<script src="/media/jui/js/jquery.min.js?275f725c29082ac9346c764233b98373"></script>

[pmleconte]

...

Tu noteras au passage que j'ai également dû laisser des unsafe-eval, ne parvenant pas non plus à être sure que j'identifierais TOUS les sha256 nécessaires à éviter ce contournement...

En fait, il s'agit d'un avertissement pour le unsafe-inline. Ce n'est pas trop grave, même si ce n'est pas recommandé.

Par contre, le unsafe-eval est plus risqué car cela peut ouvrir une porte pour entrer du code dans les scripts.Il faut essayer d'en trouver l'origine pour le corriger.

Pascal

[pmleconte]

pmleconte



Re : SHA-256
Est-ce ce dont tu parles - la série de chiffres après jquery.min.js ?
<script src="/media/jui/js/jquery.min.js?275f725c29082ac9346c764233b98373"></script>

Bonjour @ghazal,

Lorsque l'on utilise le plugin httpheader avec le CSP en mode Report-only, il donne des lignes d'erreur du style :

 Refused to apply inline style because it violates the following Content Security Policy directive: "default-src self". Either the 'unsafe-inline' keyword, a hash ('sha256-XBktW0Mp2TfPdPHpwCZUiKf6wfiQLisX4jMSFjzNu1s='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

Je dois t'avouer que je n'ai pas vérifié s'il s'agissait du même code mais je pense que le code que tu as correspond plutôt à un code de fichier cache, mais, là, tu me poses une colle...

Bon dimanche,

Pascal

[Eddy.vh]

Pascal.

J'ai un unsafe-eval à cause de Jcomments. Sans l'instruction, le composant fonctionne mais le composant ne recharge pas après la soumission d'un commentaire, ce qui laisse penser que le comm. n'a pas été enregistré.
As-tu une idée pour cibler et ajouter une csp précise pour éviter cet unsafe-eval ?

[FlodAriege]

En fait, il s'agit d'un avertissement pour le unsafe-inline. Ce n'est pas trop grave, même si ce n'est pas recommandé.

Par contre, le unsafe-eval est plus risqué car cela peut ouvrir une porte pour entrer du code dans les scripts.Il faut essayer d'en trouver l'origine pour le corriger.

Pascal

Bonjour Pascal,

J'ai trouvé d'où ça vient : des boutons de partage gérés par Addthis.
Je ne comprends pas pourquoi, alors que mes directives autorisent déjà divers domaines addthis, il faut, en plus, ce "eval".
Quoi qu'il en soit : pas de unsafe-eval = pas de boutons de partage.
C'est pas dit que je ne finisse pas par les supprimer.
Mais il faut pour ça que je fasse le "deuil" du travail déjà réalisé pour dimensionner des images au format twitter-card, des textes saisis pour les RS, etc...

Dans Report URI, je lis ceci pour les 3 eval rencontrés :

"csp-report": {
        "document-uri": "https://www.mondomaine.fr/titre-article.html",
        "effective-directive": "script-src",
        "original-policy": "default-src 'self'; report-uri https://mondomaine.report-uri.com/r/d/csp/reportOnly",
        "blocked-uri": "eval",
        "line-number": 2,
        "column-number": 124863,
        "source-file": "https://s7.addthis.com"

Pourquoi diable, alors que mes CSP autorisent

*addthis.com

faut-il en plus autoriser ces "eval" ?

Et surtout, existe-t-il un moyen de les autoriser en les ciblant mieux qu'avec un 'unsafe-eval' ? En fait, je pensais que j'allais trouver des sha256 ou quelque chose d'équivalent, mais pas du tout. Il n’apparaît rien d'exploitable dans la console dans cet objectif...

Merci.


Ah ! J'allais oublier !!
Pour toutes les directives pour lesquelles je n'ai obtenu aucun résultat dans le rapport généré sur Report URI, je n'avais rien fait.
Alors, pour tout ça :
child-src : 0 résultat
default-src : 0 résultat
manifest-src : 0 résultat
media-src : 0 résultat
object-src : 0 résultat
worker-src : 0 résultat

... j'ai ajouté, en dernier lieu, un :
default-src 'self'
J'ai bien fait ?

Et, en lisant le rapport d'analyse Dareboost, j'ai appris aussi que :

Votre page contient des liens relatifs. Pour transformer ces liens relatifs en URLs complètes, le navigateur se basera sur la valeur de votre élément <base>.
En cas d’attaque de type XSS (Cross-Site Scripting), un attaquant pourrait modifier la valeur de l’attribut href de votre <base> dans l’optique de détourner une partie de votre trafic vers un autre site web. Définissez une politique de sécurité limitant les domaines possibles dans les valeurs d’un élément <base>.

Du coup, j'ai ajouté une règle :
base-uri 'self'

Reste encore à savoir quoi faire avec :
plugin-types : 0 résultat
form-action : 0 résultat
frame-ancestors : 0 résultat
navigate-to : 0 résultat
block-all-mixed-content : 0 résultat
upgrade-insecure-requests : 0 résultat
require-sri-for : 0 résultat
unknown : 0 résultat
... liste parmi laquelle celui qui m'interroge le plus, c'est le form-action : que faut-il mettre comme règle ? 'self' ??

[pmleconte]

Pascal.

J'ai un unsafe-eval à cause de Jcomments. Sans l'instruction, le composant fonctionne mais le composant ne recharge pas après la soumission d'un commentaire, ce qui laisse penser que le comm. n'a pas été enregistré.
As-tu une idée pour cibler et ajouter une csp précise pour éviter cet unsafe-eval ?

Je n'avais pas vu ce unsafe-eval pour JComments.

Il vient du fichier jcomments.js à cause de l'utilisation de la classe Math qui est considérée par CSP à l'identique que eval.

Je n'ai pas trouvé de paramètre sauf à modifier le composant JComments

Pascal

[Eddy.vh]

Je n'avais pas vu ce unsafe-eval pour JComments.

Il vient du fichier jcomments.js à cause de l'utilisation de la classe Math qui est considérée par CSP à l'identique que eval.

Je n'ai pas trouvé de paramètre sauf à modifier le composant JComments

Pascal

Merci pour ton retour.
Je sais que daneel avait bosse sur Jcomments mais il la pas encore fait de retour.

Flo.
Le default-src doit, je pense, se trouver en tête de liste.
Tu peux le glisser en haut de la pile dans le plugin.

Quand tu n'as plus d'erreurs, il est inutile d'ajouter d'autres règles.

[pmleconte]

Après quelques tests complémentaires, ce n'est pas la classe Math qui coince, mais le setTimeout suivi de texte (voir https://stackoverflow.com/questions/...-in-firefox-os). Donc la correction pourra venir de la modification de la fonction fade (ligne 295 du jcomments.js) qui est le seul endroit où setTimeout est suivi de texte.

Il faut remplacer le texte par un appel à une "function"

Pascal

[pmleconte]

Donc, pour essayer, j'ai remplacé la fameuse ligne 295 du fichier jcomments-v2.3.js avec

fade: function(id,s,e,m){var speed=Math.round(m/100),timer=0;if(s>e){for(var i=s;i>=e;i--){setTimeout(function() {JComments.prototype.setOpacity('"+id+"',"+i+")},(timer*speed));timer++;}var o=JComments.prototype.$(id);if(o){setTimeout(function(){o.style.display='none';},((s-e)*speed));}}else if(s<e){for(var i=s;i<=e;i++){setTimeout(function(){JComments.prototype.setOpacity('"+id+"',"+i+")},(timer*speed));timer++;}}},

Et, en supprimant le unsafe-eval de mon CSP, cela semble fonctionner correctement, même si le fade me semble un peu trop rapide.

Pascal

[Eddy.vh]

Merci Pascal. Je teste au plus vite.

[FlodAriege]

Flo.
Le default-src doit, je pense, se trouver en tête de liste.
Tu peux le glisser en haut de la pile dans le plugin.

Quand tu n'as plus d'erreurs, il est inutile d'ajouter d'autres règles.

Je peux glisser les "modules" contenant les règles mais... ils ne changent pas d'ordre. Ils glissent, mais dès que je les relâche, ils reviennent à leur position initiale...
Si j'y pense, je referai la saisie dans l'ordre.

Le default-src couvre les trucs-src, mais pas, par exemple, le base-uri. Je lis aussi, notamment sur Dareboost, qu'il faudrait bannir les frame-ancestors (avec un 'none'). Quant aux autres directives, il faudrait que j'aille un peu plus loin dans mes lectures pour savoir...

Merci à tous pour votre aide !
@ +

[jfque]

Une chose à garder à l'esprit aussi est que la sécurité à 100 % n'existe pas. Si quelqu'un VEUT rentrer chez vous, il finira toujours pas y arriver. Heureusement, dans 99,99% des cas, les pirates ne veulent pas entrer CHEZ VOUS, mais là où c'est (assez) facile. Le but est donc de leur rendre la tâche aussi compliquée que possible, sans rendre son propre travail et son propre usage du site inutilement compliqué.

En théorie, oui, un "unsafe-inline" n'est pas une bonne chose, mais s'il y a un réellement un script malveillant sur votre serveur qui utilise "eval", c'est qu'un pirate a eu accès à celui-ci et, donc, les problèmes sont beaucoup plus sérieux parce que s'il a accès aux fichiers, il peut très bien modifier votre fichier .htaccess pour en changer les règles. Ce serait différent si la CSP était activé au niveau du serveur lui-même (c'est ce que je fais pour mes clients), mais si elle est dans un fichier à la racine du site ...

En résumé, une note "A" est suffisante avec une autorisation pour les sites extérieurs admis, et puis, une bonne protection du serveur lui-même : accès au fichiers en SFTP seulement, chager le mot de passe régulièrement, protéger la console d'hébergement, ....