Un nouveau procédé de sécurité visant à prémunir les sites internet des XSS (Cross-Site Scripting) sera bientôt mis en place sur Firefox (pas avant novembre). Le Cross-Site Scripting permet via l'injection d'un script JavaScript (distant en général) de compromettre un site, et d'y voler les données des utilisateurs (via les cookies) ou les faire effectuer des actions indésirables en modifiant dynamiquement le code de la page.
La Content Security Policy (CSP) consiste en une en-tête HTTP nommée X-Content-Security-Policy renvoyé par le serveur et pouvant accepter différentes valeurs. Le but étant d'empêcher le chargement d'image, de script distant non-autorisé ou l'exécution de certaines fonctions JavaScript. Tout un panel d'options est disponible dans le cahier des spécifications des SCP (en). Ce système n'affectera pas les navigateurs ne supportant pas la directive X-Content-Security-Policy.
Il sera par exemple possible de désactiver l'exécution du code JavaScript placé dans le corps de la page :
- Les éléments
<script> - Les urls JavaScript
<a href="javascript:..."> - Les événements
<a onclick="...">
... mais de préserver les fichiers de script externes servis en Content-Type application/javascript ou application/json.
On pourra également désactiver la création de code depuis les chaînes de caractères :
- à l'aide des fonctions
eval(),setTimeout,setInterval - à l'aide du constructeur de fonctions
new Function("code malicieux...")
... et ainsi de suite, en obtenant un effet cumulatif pour chaque directive de sécurité mentionnée.
Au point de vue de l'en-tête HTTP, différents exemples sont fournis, nous obtenons par exemple pour n'autoriser que les ressources d'un même domaine :
X-Content-Security-Policy: allow 'self'ou n'autoriser que le chargement de certaines ressources depuis des domaines bien précis :
X-Content-Security-Policy: allow 'self'; img-src *; script-src scripts.domainesecurise.comDans ce cas, nous autorisons le chargement des images (<img src="..." />) depuis tous les domaines, mais celui des scripts (<script src="..." />) uniquement depuis scripts.domainesecurise.com.
Attention, ceci ne sera pas anodin pour le code des pages HTML : il y aura évidemment des tests approfondis à faire sur chacun des sites. Le but de cette balise est justement de prévenir que les tests ont bien été effectués et que le code source respecte une certaine norme.
Pour le moment seul Mozilla souhaite intégrer ce système, mais il est tout à fait probable que les autres éditeurs l'intègrent aussi à plus long terme.
Article complété par dew
Commentaires
Donc, en pratique, il s'agirait d'ajouter cet header à nos pages afin que Firefox (et éventuellement d'autres navigateurs plus tard) empêchent le chargement de certains contenus depuis des sites distants ?
Est-ce que ce n'est pas déjà possible avec les languages côté serveurs actuels ?
Je suis un peu novice dans le domaine de la sécurité et j'avoue ne pas trop saisir la nouveauté.
En effet, tout cela est possible côté serveur. Mais comme personne n'est parfait ... en mettant ça les utilisateurs de firefox n'auront aucun risque sur les sites ayant ce tag. Mais dew pourrait t'en parler beaucoup mieux que moi.
Tout cela n'est possible que côté serveur, on parle d'une entete HTTP, donc pas dans le code de la page.
C'est très facile en PHP et en ASP (les langages que je connais) d'ajouter une entete HTTP. En revanche, rien à faire au niveau XHTML pour ce qui est de cette entete. L'article parle de vérification et de lien dans la page, là c'est autre chose.
ah oui en effet Nickko. Et en faites merci à Dew d'avoir complété l'article. Je comprends un peu mieux le truc maintenant.
Bonjour,
ça m'étonne que ce ne soit pas d’ores et déjà possible côté serveur.
Et si c'est faisable, je ne voix plus l'intérêt de cette en-tête.
Donc il s'agit d'en-tête envoyé par le serveur qui dit à Firefox d'empêcher le chargement de scripts et autres éléments chargés depuis un serveur distant ?
Le vrai intérêt de la chose est donc de rendre l'utilisation de cette méthode plus courante, vu qu'on peut déjà le faire en php, asp et cie, c'est ça ?
Bah non on ne peu pas empêcher en php (ou autre) qu'un visiteur du site puisse charger un script javascript d'un site non désiré. On entend ici qu'un pirate aurait réussi d'une façon ou d'une autre (et il y en a plein) à posé un code malveillant dans la page grâce à un formulaire de commentaire ou autre ...
Sans ça il est facile pour le pirate de récupérer la session de l'internaute et voir même celle de l'administrateur du site.
@Skoua : pour plus de clareter. Si dans mon html j'ai comment le php ou l'asp peut empêcher l'internaute d'aller récupérer le script externe. Réponse grâce à un message dans l'entête http qui indique que tout les scripts ne provenant pas de www.mondomaine-secure.org ne sont pas admis. Et voilà vive firefox !
Zut mon bout de code n'est pas passé. (justement ce site est bien sécurisé :) )
Entre "dans mon html j'ai" et "comment le php..." il fallait lire :
script scr=www.domaine-pirate.info/tresmechant.js (en balise html)
Juste une précision : cela n'a rien à voir avec PHP ou ASP, c'est uniquement du ressort de HTTP et HTML. Actuellement on ne peut pas interdire l'exploitation de ces failles au niveau du serveur serveur, cela ne présente pas d'intérêt, sinon tous les sites auraient déjà mis en place de telles règles.
On peut interdire l'utilisation de fichiers *provenant* d'une requête effectuée sur un certain site comme vous le mentionnez, mais pas l'inverse.
La situation est totalement différente ici : il s'agit d'interdire *sur son propre site* d'exploiter un script hébergé *sur un autre* serveur quelconque (qui ne serait bien sûr pas protégé), ou tout simplement d'une injection faite sur la page elle-même, via un formulaire par exemple.
J'entendais par côté serveur, le fait d'envoyer une en-tête qui bloque les fichiers de sources externe ou définies. C'est vraiment étonnant que ça n'existe pas, ça n'empêcherai pas les failles mais éviterai de gros soucis.
Faut que tout les navigateurs s y mettent maintenant.
Merci à vous deux j'ai compris, j'avais pris le truc à l'envers.
En effet dans ce cas-là c'est intéressant en effet.
Et donc cette fonction serait effective dans Firefox 3.6 a priori ?
Dans l'article de Zdnet, Johnathan Nightingale parle du après la version 3.6. Qui est prévu pour Novembre. Donc il faudra surement attendre une 3.7 ou une mise à jour de la 3.6
On peut penser qu'une communication spécifique sera fait là dessus... le but n'est de faire passer cette fonctionnalités en toute discrétion sans que personnes ne s'en aperçoive.
@dew : Oui enfin pour envoyer une entete http, sur un serveur mutualisé tu fais comment ?
Moi je vois bien la solution avec un langage côté serveur.
@Nickko : header est ton ami http://fr2.php.net/manual/en/function.header....
Juste une réflexion comme ça mais les plugins genre greasedmonkey qui permet de charger des script externe et de modifier le contenu de la page, ou les bookmarklet qui te permettent d'inspecter le contenu d'une page genre xray ... ça ne marchera donc plus ... non ? C'est un peu limite sous couvert de sécurité de priver les internautes de pleins d'outils ... peut être plutôt que de bloquer le chargement prévenir l'utilisateur qu'un contenu non autoriser cherche à se loader ...
ou avec un fichier .htaccess. Une page html de base est aussi envoyée avec une en-tête http (comme tout les fichiers envoyés par le serveur) ça ne passe pas forcément par un programme.
@Clawfire : Pas évident que cela soit bloqué vu que greasedmonkey charge des scripts externe à la demande de l'internaute et non d'un pirate malveillant. Et pour ce qui est de la demande du chargement d'un script externe, cela risque de faire la même chose que le système de demande d'exception sur les clef sécurisés des sites qui ont oubliés de renouveler leur jeu de clef.
A l'aide des fonctions header en effet, ou de .htaccess
@masseuro : ce qui, sous firefox, est particulièrement mal foutut (la gestions des certificats ou clé arrivées a expiration) ... enfin c'est mon avis
@masseuro : Oui c'est ce que je disais en réponse à @dew, ça a bien un rapport avec un langage côté serveur. cqfd.