Header CSP : la quasi-impossibilité de sa mise en oeuvre sur WordPress

Captainigloo m’a fait part que, pour un expert en sécurité informatique, j’étais tout de même une tanche ! Il faut dire qu’il m’a infligé un coup fatal, en m’indiquant que mon site était un site de classe B au regard du site securityheaders.io. Alors, j’ai voulu le rassurer et surtout lui faire plaisir en le passant immédiatement en A. Rien que pour ça, il doit en être remercié. Pour le A+, en revanche, mon Capitaine Igloo dont le site est en D, c’est tout juste impossible !

Header CSP : la quasi-impossibilité de sa mise en oeuvre sur WordPress

Header Content Security Policy

L’entête CSP Content Security Policy a été conçu pour garantir à l’internaute qu’il visionnait bien les contenus du site sur lequel il naviguait. Dans l’hypothèse où un site se fait hacker, rien n’empêche alors de mettre dans les entêtes des pages du site la balise meta suivante :

<meta name="content-security-policy" content="default-src 'self' data: http: https: 'unsafe-inline' 'unsafe-eval'">

Tu parles d’une protection ?!

Si le hacker accède au fichier de configuration du serveur Web Apache, alors il peut ajouter dans la configuration générale la ligne suivante :

Header always set Content-Security-Policy "default-src 'self' data: http: https: 'unsafe-inline' 'unsafe-eval' ;"

Comment sur un site WordPress, truffé de plugins, de scripts « inline » utilisant à l’occasion la fonction eval, le Content Security Policy pourrait-il s’appliquer ? Pour un site de e-Commerce, c’est une toute autre histoire et il faudrait, de mon point de vue, se donner vraiment la peine de configurer le header CSP avec soin.

Sécurité  / Apache Formateur Apache Formateur Sécurité informatique Formateur WordPress Wordpress 

Commentaires

L’usage des option ‘unsafe-*’ sont dangereuses ; cela se comprend aisément.
Sincèrement, les utiliser revient à ne pas être protéger du tout. Autant ne pas mettre de CSP, puisque de toute façon, avec ces options CSP, on permet l’exécution et l’analyse de n’importe quel code.
Bref, oui, vous avez mis du CSP en place… mais de manière « leurrée ».
Si vous regardez l’encadré « Warning », le site annonce de l’état de danger dans lequel vous mettez vos données.

J’ai le même soucis pour mon Blog, où je suis obligé à cause de site tierce d’ajouter dans les contextes de ‘script-src’, et ‘style-src’ l’option ‘unsafe-inline’. Cela ne me plaît guère. Mais obligé de faire.
C’est – à mon avis – le problème de ces technologies|outils, d’un temps passé, où n’existait pas encore ces mesures de sécurité. Maintenant, il va falloir que les développeurs s’adaptent à cela, sans choisir les solutions de facilités que sont ces options dangereuses…
Que ce soit WP, DC – dotclear, DW – Dokuwiki, ou autres, c’est le même « combat » !

J’ai essayé d’ailleurs sur mon blog de vulgariser – ce qui en soit est une gageure – les CSP ; personnellement, sans aucune prétention que celle « d’aimer » l’IT ;)
https://blog.stephane-huc.net/web/http/csp

Voili, voilou…

@HucSte

Pas mieux. Le pire, c’est le ‘unsafe-eval’. J’en ai partout !

Merci pour les conseils prof =)

Laisser un commentaire

(requis)

(requis)