Depuis le 30 mai, Content Security Policy (CSP) 1.0 est supporté par Firefox, dans le canal Aurora (version pre-beta de Firefox). C'est une bonne occasion de parler de cette nouvelle méthode de protection de l'utilisateur qui tend à être intégrée dans tous les navigateurs.
Content Security Policy ?
CSP est un mécanisme de sécurité dont le but est de protéger l'utilisateur contre les failles XSS (cross-site scripting) en permettant aux sites web de restreindre l'origine des scripts. CSP a été crée par la fondation Mozilla, et les premières implémentations ont été intégrés à Firefox 4. Depuis le 15 novembre 2012, c'est même une recommandation candidate du W3C, et c'est cette version qui sera intégrée dans Firefox 23.
NdM : merci à xenom pour son journal.
Pourquoi ?
La sécurité des navigateurs web au niveau des scripts repose sur la same origine policy, qui restreint l'accès aux données du site aux scripts provenant du même site. Par exemple un script situé sur https://linuxfr.org a accès aux données, comme les cookies, provenant uniquement de https://linuxfr.org et ne pourra pas lire les données provenant de http://example.org.
Sauf que cette restriction peut être contournée en injectant les scripts malicieux dans le contenu de la page, et repose sur la non-capacité des navigateurs à reconnaître un script légitime d'un script qui aurait été injecté. C'est le principe des attaques XSS.
C'est pour éviter cela qu'a été créé CSP.
Comment ça marche ?
L’entête HTTP Content-Security envoyée avec la page contient une liste des domaines d’où peuvent provenir les différents scripts. Pour que ce soit efficace, le Javascript inline est bloqué, tout comme les fonctions comme eval qui permettrait l’exécution de code.
Si un attaquant injecte un script situé sur un domaine non autorisé par la CSP, le navigateur refuse de l’exécuter. CSP va même plus loin en donnant le contrôle sur la provenance d'autres ressources, comme les images, les frames ou les polices.
Quelles différences avec NoScript ?
Déjà, CSP est intégré de base au navigateur contrairement à cette extension. Ensuite et surtout, la source du filtrage est différent, NoScript est configuré par l'utilisateur, CSP par le webmaster.
CSP ne protégera donc pas l'utilisateur des scripts malveillants ou de tracking si ils ont été mis en place et autorisés par le webmaster, ni des MITM si l'attaquant modifie aussi l’entête CSP.
Qui le prend en charge ?
La plupart des navigateurs, mais souvent dans une version expérimentale avec des préfixes particuliers. Seul Chrome et les futures versions de Firefox implémentent la recommandation complètement et avec les entêtes définies dans la version 1.0.
Safari utilise des entêtes X-WebKit-CSP, Internet Explorer uniquement une version partielle depuis sa version 10. Opera ne supporte pas CSP, mais cela devrait être le cas dans sa prochaine version.
Si le navigateur ne le supporte pas, cela n'aura pas d'impact visible pour l'utilisateur, CSP ne sera juste pas pris en considération.
Voici un tableau sur la compatibilité des navigateurs avec CSP.
Envie d'en savoir plus ?
Je conseille la lecture de cet article très complet, et de l'annonce sur le blog de Mozilla.
Pour aider à l’écriture de la politique de sécurité, Mozilla a sorti une extension Firefox. Cette extension permet aussi aux utilisateurs de définir une politique CSP pour des sites ne la supportant pas encore.
Aller plus loin
- Journal à l'origine de la dépêche (51 clics)
# il faut aussi un CSP contrôlable par l'utilisateur
Posté par kadalka . Évalué à -9.
Si le WebMaster n'est pas honnête, le risque est bien réel…
Par exemple, la majorité qui n'y connaît rien en JavaScript seraient donc dans une situation plus que délicate puisque la plupart ont JavaScipt autorisé sans restriction.
Mais pourquoi ne pas aussi mettre une option qui permette un minimum de protection XSS que l'utilisateur pourrait contrôler avec possibilité de RESET (dès fois qu'il fait l'erreur de tout zapper) ?
Parce que l'utilisateur n'aura que rarement envie de mettre du NoScript.
Je me souviens qu'une fois NoScript m'a empêché d'accéder une page à cause d'un problème ABE…
Si ce genre de problème survient, il est évident que l'utilisateur lambda va désactiver NoScript. Non?
J'ai mal lu ? Une recommandation utile, même release candidate, ne doit-elle pas être intégrée ?
On parle bien de sécurité de l'utilisateur, non ?
[^] # Re: il faut aussi un CSP contrôlable par l'utilisateur
Posté par ariasuni . Évalué à 5.
Tes deux phrases n’ont aucun rapport. Mais mieux vaut CSP qui permet à certains webmestres (et bien sûr les CMS) de sécuriser leur site/appli web que pas de CSP et personne et que personne ne sois protégé.
Ça permet de protéger l’utilisateur lambda sans qu’il n’ai rien à faire, puisque de toute façon c’est la personne qui ne se protègera pas.
C’est pas parce que le HTML5 c’est pas encore terminé que c’est «instable»… D’ailleurs c’est au niveau des implantations que c’est stable ou pas (et donc c’est là que ce situe la sécurité), et si le brouillon est presque définitif je ne vois pourquoi ne pas l’activer dès maintenant.
De toute manière ça ne sera pas tellement utilisé avant un moment, donc ça permet de tester sérieusement la chose sans compiler des trucs de fous. Donc on prend de l’avance, après on améliore un peu au fur et à mesure, mais au moins le boulot est fait avant que ça soit implanté un peu partout et donc une faille aujourd’hui dans cette fonctionnalité est beaucoup moins grave que si ça avait été fait dans 10 versions.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: il faut aussi un CSP contrôlable par l'utilisateur
Posté par xenom . Évalué à 1.
J'ai compris ce commentaire dans l'autre sens, pourquoi ce n'est pas encore intégré.
En fait c'est déjà en partie intégré et à plusieurs niveaux.
CSP a été crée par la fondation Mozilla, et est intégré à Firefox depuis la version 4, qui est sortie en mars 2011. Sauf que à l’époque, c'est n’était qu'une première version et le préfixe était "X-Content-Security-Policy".
Depuis ça a fait son chemin est c'est devenu une recommandation candidate, et pas une recommandation W3C (voir wikipedia pour la difference), et c'est cette version qui est en cours d'intégration dans Firefox, et comme dit dans la dépêche déjà disponible dans Firefox Aurora, qui est la pré-beta.
# Erreur : oubli d'un i
Posté par RyDroid . Évalué à 2.
"failles XSS (cross-site scr**i**pting)"
Au passage la prévisualisation ne marche pas pour le gras (sous FF 21).
[^] # Re: Erreur : oubli d'un i
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Typo corrigée, merci.
[^] # Re: Erreur : oubli d'un i
Posté par ariasuni . Évalué à 2.
Rien à voir, faut laisser une espace de chaque côté:
cross-site scr **i** ptingCe qui donne: «cross-site scr i pting.»
Le Markdown n’a pas été fait pour ce genre de choses… Et visiblement les balises html sont zappées.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Erreur : oubli d'un i
Posté par anaseto (site web personnel) . Évalué à 2. Dernière modification le 15 juin 2013 à 09:37.
Vu qu'il n'y a pas vraiment de spécification, c'est un peu le bazard des fois, mais pour le coup ça sent un peu le bug dans les regexps.
Avec pandoc par exemple ça marche comme on l'imagine, sans besoin d'espaces. Avec l'implémentation en perl, ça plante aussi (le plus rigolo c'est que si on met ma**r**kdown on obtient ma*<em>r</em>*kdown). Je pense que chacune a un comportement différent ;)
[^] # Re: Erreur : oubli d'un i
Posté par Bruno Michel (site web personnel) . Évalué à 7.
En fait, le comportement par défaut de Redcarpet (la bibliothèque Ruby utilisée sur LinuxFr.org) est le même que celui de pandoc. Mais on utilise l'option
no_intra_emphasisqui désactive l'italique et le gras à l'intérieur des mots. On fait cela surtout parce qu'il est assez fréquent d'avoir des soulignés dans les mots techniques et que l'on veut éviter de transformer no_intra_emphasis en nointraemphasis.[^] # Re: Erreur : oubli d'un i
Posté par anaseto (site web personnel) . Évalué à 3.
Ah, j'avais pas pensé qu'on risquerait d'avoir souvent des trucs bizarres quand on oublie de mettre en style code. Et puis c'est vrai que mettre du gras à l'intérieur d'un mot, c'est pas très utile (si c'est juste pour relever les fautes d'orthographe… on peut se débrouiller sans ;) ).
# Bookmarklets
Posté par catwell (site web personnel) . Évalué à 2.
Évidemment, la spec dit que CSP ne devrait pas empêcher les bookmarklets de fonctionner, Mozilla dit que CSP ne devrait pas empêcher les bookmarklets de fonctionner et l'implémentation… empêche les bookmarklets de fonctionner. Problème connu chez Mozilla depuis 2009 (!) qui me force à complètement désactiver CSP (
security.csp.enable = false) juste pour utiliser Pinboard.[^] # Re: Bookmarklets
Posté par Julien Wajsberg . Évalué à 2.
as-tu un numéro de bug ? Ton lien "connu chez Mozilla" pointe vers un commentaire sur un message de blog, ya plus efficace comme retour :)
[^] # Re: Bookmarklets
Posté par claudex . Évalué à 5.
https://bugzilla.mozilla.org/show_bug.cgi?id=866522
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.