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 Content Security Policy 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…

Si tu as des inline, tu as un problème d’optimisation
Si tu as des eval() en PHP ou en Javascript, tu as un immense problème de sécurité
Si ton CMS permet d’inclure directement du PHP dans tes fichiers de template, tu as un très très gros souci d’architecture
Si tu ne sais pas comment gérer les droits utilisateurs pour resteindre su, sudo et n’autoriser que root à jouer avec /dev, c’est que tu as un immense problème d’administration système.

pardon /etc , pas dev/

@HucSte

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

@Da Scritch

C’est du WordPress, avec les plugins qui vont bien. Dis-moi, la sécurité de ton site n’est pas terrible non plus ?

-> https://securityheaders.io/?q=https%3A%2F%2Fdascritch.net%2F

Merci pour les conseils prof =)

@Da Scritch
Je suis surpris de voir que votre site est configuré avec ‘unsafe-eval’ ‘unsafe-inline’ directement pour le default-src ce qui est justement la bse de cet article. Vos commentaires reviennent à dire que votre site a potentiellement un « problème d’optimisation » et un « immense problème de sécurité ».

Les cordonniers les plus mal chaussés ? Ou faites ce que je dis et pas ce que je fais ?

Je déborde du sujet mais en passant je vous recommande de mettre un X-Frame-Options à SAMEORIGIN ou à DENY et de modifier votre Referrer-Policy à no-referrer ou same-origine.
Et pour votre certificat SSL/TLS, je vous suggère de désactiver le protocole TLS 1.0 même si ce n’est pas obligatoire.

Bien qu’étant globalement vrai, par une mise en pratique vos propos aurais alors plus de sens.

Mais je reconnais aussi que vos configurations sont bien plus sécurisés que bien des sites que j’audite.

Bonne configuration.

Laisser un commentaire

(requis)

(requis)