[Dotclear Dev] CSP côté admin
Franck Paul
Je vais intégrer les CSP (content security policies) côté admin et en more
reporting pour l'instant dans mon prochain commit (et donc dans la nightly
de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire en
cas de violation de la directive, un rapport dans le fichier texte
/admin/csp_report.txt
Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu avec
l'admin, et me retourner le contenu du fichier csp_report.txt si jamais il
était créé et pas vide ?
À noter que cette directive, si jamais elle était trop restrictive, peut
assez vite foutre en l'air une admin (et encore plus la partie publique
d'un blog), c'est la raison pour laquelle j'y vais doucement.
Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
comment gérer la partie publique (largement plus complexe puisqu'on peut
intégrer des éléments de sources variées dans un blog).
Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
visionner ceci →
https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
À vous lire…
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
--
Dev mailing list - D...@list.dotclear.org - http://ml.dotclear.org/listinfo/dev
mirovinben
Donc après PHP 5.3 annoncé comme prérequis pour Dotclear 2.9, voilà PHP 5.4 pour Dotclear 2.10... Et les utilisateurs qui n'ont pas la possibilité de changer facilement de version PHP vont faire quoi ?
Ceci dit, je vais essayer de comprendre à quoi peut servir les CSP.
A propos, "security" et "policy" c'est-y lié au prolongement de l'état d'urgence ou bien...? :-)
Le 20/07/2016 à 09:37, Franck Paul a écrit :
> Bonjour,
>
> Je vais intégrer les CSP (content security policies) côté admin et en more
> reporting pour l'instant dans mon prochain commit (et donc dans la nightly
> de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire en
> cas de violation de la directive, un rapport dans le fichier texte
> /admin/csp_report.txt
>
> Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu avec
> l'admin, et me retourner le contenu du fichier csp_report.txt si jamais il
> était créé et pas vide ?
>
> À noter que cette directive, si jamais elle était trop restrictive, peut
> assez vite foutre en l'air une admin (et encore plus la partie publique
> d'un blog), c'est la raison pour laquelle j'y vais doucement.
>
> Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
> comment gérer la partie publique (largement plus complexe puisqu'on peut
> intégrer des éléments de sources variées dans un blog).
>
> Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
> visionner ceci →
> https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
>
> À vous lire…
>
--
Franck Paul
Depuis la sortie de PHP 5.6, la configuration est :
- branche de développement : 7.0 ;
- branches encore supportées (corrections de bugs et de la sécurité) :
5.6, 5.5 ;
- branche en obsolescence et ne recevant que des correctifs de
sécurité : 5.4 ;
- toutes les branches < 5.4 ne sont plus supportées.
Donc il est possible que la 2.10 nécessite PHP 5.4, version qui est d'ores
et déjà obsolète, et la 2.11 peut-être PHP 5.5 ou 5.6.
Quoi qu'il en soit je recommande vivement PHP 7, le gain de perf est
impressionnant ! Sinon PHP 5.6 c'est bien. Quant à la version 5.3 de PHP,
la conserver c'est s'exposer à plus ou moins brève échéance à des problèmes
de sécu.
Cf https://fr.wikipedia.org/wiki/PHP
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
Franck L
Yep. Je teste ça sur mon install de test en local. Ça marche pour du
local, ou il est préférable de tester en ligne, d'ailleurs ?
Tomek
Le 20/07/2016 à 09:37, Franck Paul a écrit :
> Bonjour,
>
> Je vais intégrer les CSP (content security policies) côté admin et en more
> reporting pour l'instant dans mon prochain commit (et donc dans la nightly
> de la nuit prochaine). Ce système, à partir de PHP 5.4, devrait produire en
> cas de violation de la directive, un rapport dans le fichier texte
> /admin/csp_report.txt
>
> Pouvez-vous tester de votre côté cette prochaine nightly, jouer un peu avec
> l'admin, et me retourner le contenu du fichier csp_report.txt si jamais il
> était créé et pas vide ?
>
> À noter que cette directive, si jamais elle était trop restrictive, peut
> assez vite foutre en l'air une admin (et encore plus la partie publique
> d'un blog), c'est la raison pour laquelle j'y vais doucement.
>
> Si tout va bien, on gardera les CSP côté admin pour la 2.10, et je verrai
> comment gérer la partie publique (largement plus complexe puisqu'on peut
> intégrer des éléments de sources variées dans un blog).
>
> Vous ne savez pas ce que sont les CSP ? Eh bien prenez 15 minutes pour
> visionner ceci →
> https://www.paris-web.fr/2015/conferences/csp-content-security-policy.php
>
> À vous lire…
>
--
Franck Paul
Sinon les miniatures des thèmes de DA ne sont pas affichées (en tout cas
jusqu'à la prochaine nightly), Annie Strohem vient de me signaler le pb et
je viens de corriger ça.
Merci pour les tests
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
Franck L
config d'url qui n'était pas bonne pour la prévisualisation.
Je n'avais pas vu pour les thèmes.
Franck Paul
http://caniuse.com/#feat=contentsecuritypolicy) , ça peut verrouiller
encore mieux côté sécu, en tout cas pour l'admin et c'est pas plus mal.
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
Franck Paul
m'a fourni le sien le premier jour ce qui m'a permis de régler un pb).
Le 21 juillet 2016 à 14:41, Franck Paul <carnet.fr...@gmail.com> a
écrit :
Franck Paul
compte tout de même :-p
Le 23 juillet 2016 à 13:03, Franck Paul <carnet.fr...@gmail.com> a
Benoit GRELIER
> Message du 20/07/16 09:38
> De : "Franck Paul"
> A : "d...@list.dotclear.org"
> Copie à :
> Objet : [Dotclear Dev] CSP côté admin
Franck Paul
il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon idée à ce
sujet.
Benoit GRELIER
_Il y a encore des bugs,
_l’implémentation n'est pas simple et demande du temps.
_Ce peut-être effectivement un bon outils de contrôle pour la phase de dev d'une application et inciter à de bonnes pratiques.
Coté admin pour dotclear, le fait d'ajout de plugins tiers plus ou moins bien conçu ne risque-t-il pas de tout casser à l'affichage?
Benoit.
> Message du 23/07/16 19:43
> De : "Franck Paul"
> A : "d...@list.dotclear.org"
> Copie à :
> Objet : Re: [Dotclear Dev] CSP côté admin
>
> Côté admin, je pense qu'on peut l'imposer. Par contre c'est côté public ou il faudra permettre un réglage beaucoup plus fin ; mais j'ai mon idée à ce sujet. Le 23 juillet 2016 à 14:51, Benoit GRELIER a écrit : > Je pence que ce service devrait être optionnel ( sous forme de module > activable/désactivable ) et non intégré en dur dans le code. > > > > > >
Franck Paul
Alors effectivement des plugins tiers peuvent s'inviter et nécessiter un
accès à des ressources externes, exemple mygmaps (merci Gvx pour le
rapport).
Du coup j'ai implémenté des réglages qui permettent de désactiver les CSP
côté admin et de compléter si besoin les directives (default, script, style
et img). Si vous avez des domaines à ajouter (ex : maps.googleapis.com
utilisé par le plugin mygmaps), ajoutez-les à la directive correspondance
(séparez chaque domaine par une espace).
En place dans la nightly de ce soir.
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
Franck Paul
fermées (au détriment du risque) :
Les scripts JS inline et l'eval sont autorisés
Idem pour les styles CSS inline
Ça vaudra peut-être le coup de donner un coup de tournevis en allant à la
chasse aux scripts et style inline et d'évaluer si l'eval JS peut être
interdit. Cela dit, maintenant qu'on a accès aux différentes directives,
tout le monde peut les modifier et faire les tests idoines. Vos rapports
seront utiles pour affiner ça.
Merci
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
Franck Paul
Je viens de reprendre un peu le code pour offrir aux plugins tiers
l'opportunité d'intégrer leur complément de directive CSP (behavior
adminPageHTTPHeaderCSP).
Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour les
plugins qui le prendront en compte.
j'ai aussi ajouté un behavior plus générique qui permet d'intervenir sur
toutes les entêtes HTP envoyées avant l'affichage d'une page de l'admin
(behavior adminPageHTTPHeaders).
Avec ça on devrait pouvoir faire ce qu'on veut côté admin.
Côté public, je pense que je vais attendre un peu de retour en "prod" avec
la 2.10 et implémenter ça pour la 2.11.
Le 24 juillet 2016 à 15:03, Franck Paul <carnet.fr...@gmail.com> a
écrit :
> Sinon et pour répondre à Benoit, j'ai choisi des directives pas trop
Philippe
> Je viens de reprendre un peu le code pour offrir aux plugins tiers
> l'opportunité d'intégrer leur complément de directive CSP (behavior
> adminPageHTTPHeaderCSP).
> Il y aura donc 2 moyen de les régler : about:config et 1 behavior pour les
> plugins qui le prendront en compte.
--
Philippe
brol
> Plop tout le monde,
> --
goret quotage powa \o/
v3291 quand le machincsp est activé, pu possible de textarea pour la
description du blog, idem pour les zones txt des widgets (en gros, pas
mal de textarea sont impactés).
sinon, je me demande quand même l'intérêt du truc sachant que nombre
de plugins tiers ne sont déjà pas à jour pour une compatibilité à 100%
avec dc2.9.1, alors en remettre une couche d'incompatibilité ne
risque pas de diminuer un peu plus le catalogue des dits plugins
tiers ?
--
brol
Franck Paul
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
Franck Paul
Le contenu du csp_report.txt est ?
Franck Paul
$core->addBehavior('adminPageHTTPHeaderCSP',array('myAdminBehaviors','adminPageHTTPHeaderCSP'));
class myAdminBehaviors
{
public static function adminPageHTMLHead($csp)
{
if (isset($csp['script-src'])) {
$csp['script-src'] .= ' maps.googleapis.com';
} else {
$csp['script-src'] = 'maps.googleapis.com';
}
}
}
devrait faire l'affaire.
Le 25 juillet 2016 à 17:50, Philippe <phil...@dissitou.org> a écrit :
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
Philippe
Avec ton code, l'API est bien chargée, mais pour faire tout
fonctionner il m'a fallu en rajouter pas mal ! En effet il y a des tas
de serveurs d'images et de scripts chez Google : le lecteur de
fichiers kml, Street View, les tuiles de cartes, les icônes, etc.
Plus les tuiles pour les cartes OpenStreetMap
Pour l'instant, je ne suis pas encore sûr d'avoir tout, et il me
faudra probablement surveiller si les serveurs changent (et comment
?), mais voici la fonction
public static function adminPageHTTPHeaderCSP($csp)
{
if (isset($csp['default-src'])) {
$csp['default-src'] .= ' fonts.gstatic.com';
} else {
$csp['default-src'] = 'fonts.gstatic.com';
}
if (isset($csp['script-src'])) {
$csp['script-src'] .= ' maps.googleapis.com';
} else {
$csp['script-src'] = 'maps.googleapis.com';
}
if (isset($csp['img-src'])) {
$csp['img-src'] .= ' maps.gstatic.com maps.googleapis.com
csi.gstatic.com khms0.googleapis.com khms1.googleapis.com
mts0.googleapis.com mts1.googleapis.com cbks0.googleapis.com
cbks1.googleapis.com tile.openstreetmap.org';
} else {
$csp['img-src'] = 'maps.gstatic.com maps.googleapis.com
csi.gstatic.com khms0.googleapis.com khms1.googleapis.com
mts0.googleapis.com mts1.googleapis.com cbks0.googleapis.com
cbks1.googleapis.com tile.openstreetmap.org';
}
if (isset($csp['style-src'])) {
$csp['style-src'] .= ' fonts.googleapis.com';
} else {
$csp['style-src'] = 'fonts.googleapis.com';
}
}
Ça ne fait pas un peu beaucoup ?
:D
--
Philippe
Franck Paul
doit pas peser bien lourd dans les échanges avec le serveur.
Maintenant c'est aussi le prix à payer pour avoir une admin à peu près
sécurisée.
Quoi qu'il en soit, on peut aussi décider d'ici la sortie de la 2.10 de ne
pas activer par défaut les CSP. J'attends de faire le bilan de tous vos
retours pour décider.
Franck Paul
fournit de bonnes indications sur les directives qui sont violées. Une fois
corrigé, tu peux vider le fichier et continuer tes tests.
Le 26 juillet 2016 à 10:28, Franck Paul <carnet.fr...@gmail.com> a
Philippe
> Maintenant c'est aussi le prix à payer pour avoir une admin à peu près
> sécurisée.
>
> Quoi qu'il en soit, on peut aussi décider d'ici la sortie de la 2.10 de ne
> pas activer par défaut les CSP. J'attends de faire le bilan de tous vos
> retours pour décider.
Une question : quid des images de la médiathèque si elles ne sont pas
sur le même domaine que l'admin du blog ?
Franck Paul
about:config (soit côté blog, soit côté réglages généraux pour toute la
plateforme).
Brol, si tu as modifié les directives, essaies d'enlever les protocoles
(mettre le domaine suffit amplement).
À savoir : on peut utiliser des wildcards (*) pour les domaines, genre *.
domaine.com
Plus de doc →
https://developer.mozilla.org/fr/docs/Web/Security/CSP/CSP_policy_directives
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
Philippe
Franck Paul
Mais je risque de tout casser d'ici le 13 août, hein ? :-D
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
brol
> Brol, si tu as modifié les directives, essaies d'enlever les protocoles
> (mettre le domaine suffit amplement).
ce qui est fun c'est que ça ne le fait que sur un blog du multi...
et si c'est un conflit avec un plugin, sachant qu'il y en a un certain
nombre d'activés comme de désactivés, ça va pas être long du tout de
déterminer qui fait son emmerdeur.
une idée pour comment débusquer ce qui coince ?
--
brol
Franck Paul
actif sur ce blog qui fout le dawa : va falloir fouiller.
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)
brol
> Brol, si ce n'est que sur un des blogs, alors c'est un plugin uniquement
> actif sur ce blog qui fout le dawa : va falloir fouiller.
on est sûr à 100% que les inactifs ne peuvent interagir ?
Franck Paul
brol
> A priori oui.
donc non à 100%...
bon, l'enquiquineur est :
dcCKEditorAddons 0.3.3
bug malgré tout dans les widgets texte quand on insère une image d'un
domaine externe : pas d'affichage.
ceci étant, comment peut-on ne pas avoir la barre d'édition dans les
widgets texte ? je ne parle pas de la masquer mais de ne pas avoir du
tout l'éditeur dckeditor (ça serait bien d'avoir le choix).
enfin : quid des plugins qui ne sont pas compatibles déjà avec dc2.9.1
(question déjà posée et zappée purement et simplement) ?
Franck Paul
de bord. Donc soit il faut rajouter le domaine correspondant côté directive
img-src du blog, soit il faut contrôler côté public du blog, ce qui peut
être acceptable vu qu'on ne doit pas changer les widgets tous les jours.
Pour l'éditeur ou pas dans les widgets, c'est un ticket à ouvrir et on peut
mettre ça au programme de la 2.10 si ce n'est pas trop compliqué, ou pour
la 2.11 à venir.
Je pense qu'il y a très peu de plugins qui ne seront pas adaptés aux CSP,
et si vraiment ça coince, les CSP peuvent être désactivées dans
about:config, donc rien de bloquant.
--
Franck — Operating Crocker’s rules (http://sl4.org/crocker.html)