Commentaire: Préface: Une fois HTML5, la sécurité du réseau a attiré une attention plus répandue. Quelles améliorations le Web a-t-il apporté à la sécurité réseau? Comment sommes-nous confrontés à la cyber-fraude et aux attaques de plus en plus dangereuses? L'article suivant parle de la dernière solution de W3C à ce problème. Si j'ai l'occasion à l'avenir, je vais effectuer un contenu HTML5 sur XSS, P3P, Homologous Policy, CORS (Cross-Domain Resource Partage) et CSP.
La politique de sécurité du World Wide Web est enracinée dans une politique homologue. Par exemple, le code ne peut accéder qu'à des données, mais n'a pas d'autorisations d'accès. Chaque source est séparée du reste du réseau, créant un bac à sable sécurisé pour les développeurs. C'est parfait en théorie, mais maintenant les attaquants ont trouvé un moyen intelligent de détruire le système.Il s'agit d'attaques de scripts Cross-Site XSS, de contournement des politiques homologues via un faux contenu et des clics. Il s'agit d'un gros problème, si l'attaquant injecte avec succès le code, une quantité considérable de données utilisateur sera divulguée.
Maintenant, nous introduisons une toute nouvelle stratégie de défense de sécurité efficace pour atténuer ce risque, qui est la politique de contenu de la sécurité (CSP).
La liste blanche
Le cœur des attaques XSS est que le navigateur ne peut pas dire si le script est injecté par un tiers ou fait vraiment partie de votre application. Par exemple, le bouton Google +1 chargera et exécutera le code à partir de https://apis.google.com/js/plusone.js, mais nous ne pouvons pas nous attendre à dire à partir des images du navigateur si le code est vraiment sur APIS.google.com ou sur APIS.evil.example.com. Le navigateur télécharge et exécute une demande de page pour tout code, quelle que soit sa source.
CSP définit l'en-tête de contenu-sécurité-PolicyHTTP pour vous permettre de créer une liste blanche de sources de confiance, afin que le navigateur exécute et rend les ressources à partir de ces sources, plutôt que de faire aveuglement tout ce qui est fourni par le serveur. Même si un attaquant peut trouver une vulnérabilité pour injecter un script, il ne sera pas exécuté car la source n'est pas incluse dans la liste blanche.
Le bouton Google +1 ci-dessus est un exemple, car nous pensons que APIS.google.com fournit du code valide, ainsi que nous-mêmes, nous pouvons définir une politique qui permet au navigateur d'exécuter des scripts de l'une des deux sources ci-dessous.
Contenu-Sécurité-politique: script-src 'self' https://apis.google.com
N'est-ce pas très simple? Script-Src peut contrôler les autorisations liées au script pour des pages spécifiées. De cette façon, le navigateur ne téléchargera et exécutera que des scripts depuis et depuis cette page elle-même.
Une fois que nous avons défini cette politique, le navigateur lancera une erreur lorsqu'elle détecte le code injecté (notez de quel navigateur il s'agit).
Les politiques de sécurité du contenu s'appliquent à toutes les ressources communes
Bien que les ressources de script soient les risques de sécurité les plus évidents, CSP fournit également un riche ensemble d'instructions qui permettent aux pages de contrôler le chargement de divers types de ressources, tels que les types suivants:
Content-Src: restreignez le type de connexion (par exemple XHR, WebSockets et Eventsource)
FONT-SRC: contrôle la source des polices de réseau. Par exemple, vous pouvez utiliser les polices Web de Google via Font-Src https://themes.googleuserContent.com.
Frame-Src: répertorie la source des cadres qui peuvent être intégrés. Par exemple, Frame-Src https://youtube.com permet uniquement des vidéos intégrées dans YouTube. .
IMG-SRC: définit la source de l'image chargée.
Media-SRC: restreignez la source de la vidéo et de l'audio.
Objet-Src: restreignez la source de Flash et d'autres plugins.
Style-Src: similaire à Script-Src, il ne fonctionne que sur le fichier CSS.
Par défaut, tous les paramètres sont allumés sans aucune restriction. Vous pouvez séparer plusieurs instructions de Semicolons, mais similaire à Script-Src https: //host1.com; script-src https://host2.com, la deuxième instruction sera ignorée. La bonne façon de l'écrire est le script-src https://host1.com https://host2.com.
Par exemple, vous avez une application qui doit charger toutes les ressources d'un réseau de distribution de contenu (CDN, par exemple https://cdn.example.net) et sachez que le contenu sans cadres et plugins est nécessaire, votre stratégie pourrait ressembler à ceci:
Content-Security-Policy: Default-Src https://cdn.example.net; trame-src 'Aucun'; objet-src 'Aucun'
détail
L'en-tête HTTP que j'ai utilisé dans mon exemple est le contenu-sécurité-politique, mais les navigateurs modernes ont déjà fourni le support via les préfixes: Firefox utilise X-Content-Security-Policy, WebKit utilise X-Webkit-CSP. À l'avenir, il passera progressivement à des normes unifiées.
La stratégie peut être définie pour chaque page différente, ce qui offre beaucoup de flexibilité. Parce que certaines pages sur votre site peuvent avoir des boutons Google +1, tandis que d'autres ne le font pas.
La liste source de chaque instruction peut être assez flexible. Vous pouvez spécifier un modèle (données:, https :), ou spécifier un nom d'hôte dans une plage (example.com, qui correspond à n'importe quelle source, tout mode et tout port de l'hôte), ou spécifier un URI complet (https://example.com:443, en particulier le protocole HTTPS, Exemple.com Nom de domaine, port 443).
Vous pouvez également utiliser quatre mots clés dans la liste des sources:
Aucun: vous pouvez vous attendre à ce que tout soit incomparable
Self: Identique à la source actuelle, mais ne contient pas de sous-domaines
dangereux en ligne: permet en ligne JavaScript et CSS
dangereux-eval: mécanismes qui permettent le texte à JS, comme EVAL
Veuillez noter que ces mots clés doivent être cités.
Bac à sable
Il y a une autre instruction qui mérite d'être discutée ici: Sandbox. Il est quelque peu incompatible avec d'autres instructions. Il contrôle principalement le comportement pris sur la page, plutôt que les ressources que la page peut charger. Si cette propriété est définie, la page se comportera comme un cadre avec l'ensemble de propriétés sandbox. Cela a un large éventail d'impact sur la page, comme la prévention des soumissions de formulaire, etc. C'est un peu au-delà de la portée de cet article, mais vous pouvez trouver plus d'informations dans la section des paramètres de logo Sandbox de la spécification HTML5.
Code en ligne nuisible
Le CSP est basé sur les listes blanches source, mais elle ne résout pas la plus grande source d'attaques XSS: l'injection de script en ligne. Si un attaquant peut injecter des balises de script contenant du code nocif (<Script> sendmyDatatoEvildotcom (); </cript>), le navigateur n'a pas de bon mécanisme pour distinguer cette balise. Le CSP ne peut résoudre ce problème qu'en interdisant complètement les scripts en ligne.
Cette interdiction comprend non seulement des balises de script intégrées dans le script, mais aussi des gestionnaires d'événements en ligne et des URL Javascrpt:. Vous devez mettre le contenu de la balise de script dans un fichier externe et remplacer JavaScript: et <a… onclick = [javascript]> par le AddeveventListener approprié. Par exemple, vous pouvez mettre le formulaire suivant:
<cript>
fonction doamazingthings () {
alert («Vous êtes incroyable!»);
}
</cript>
<button> Suis-je incroyable? </futh>
Réécrivez-vous au formulaire suivant:
<! - Incroyable.html ->
<script src = 'incroyable.js'> </ script>
<button> Suis-je incroyable? </futh>
// incroyable.js
fonction doamazingthings () {
alert («Vous êtes incroyable!»);
}
document.addeventListener ('DomConTentered', fonction () {
document.getElementByid ('incroyable')
.AdDeventListener ('click', doamazingthings);
});
Que vous utilisiez ou non CSP, le code ci-dessus présente en fait de plus grands avantages. En ligne JavaScript mélange complètement la structure et le comportement, vous ne devriez pas le faire. De plus, les ressources de sensibilisation sont plus faciles à cacher dans les navigateurs, plus faciles à comprendre pour les développeurs et sont faciles à compiler et à comprimer. Si vous utilisez du code de sensibilisation, vous rédigerez un meilleur code.
Les styles en ligne doivent être traités de la même manière, les attributs de style et les balises de style doivent être extraits dans la feuille de style externe. Cela peut empêcher toutes sortes de fuites de données magiques.
Si vous devez avoir des scripts et des styles en ligne, vous pouvez définir la valeur «dangereuse en ligne pour l'attribut script-src ou style-src. Mais ne faites pas ça. Les scripts en ligne interdisant sont la garantie de sécurité maximale fournie par CSP. Dans le même temps, les styles en ligne interdits peuvent rendre votre application plus sûre et plus robuste. C'est un compromis, mais cela en vaut la peine.
Évaluer
Même si un attaquant ne peut pas injecter directement le script, il peut induire votre application pour convertir le texte inséré en un script exécutable et l'exécuter lui-même. EVAL (), newFunction (), setTimeout ([String], ...) et setInterval ([String], ...) peuvent tous devenir des porteurs aussi dangereux. La stratégie de CSP pour cibler ce risque est de bloquer complètement ces vecteurs.
Cela a des implications sur la façon dont vous créez votre application:
Parse JSON via JSON.Parse intégré sans compter sur Eval. Les navigateurs après IE8 prennent en charge les opérations JSON locales, ce qui est complètement sûr.
Réécrivez la méthode d'appel de setTimeout et setInterval par des fonctions en ligne au lieu des chaînes. Par exemple:
setTimeout (document.QuerySelector ('a'). style.display = 'Aucun';, 10);
Peut être réécrit comme:
setTimeout (function () {document.QuerySelector ('a'). style.display = 'Aucun';}, 10);
Évitez les modèles en ligne au moment de l'exécution: de nombreuses bibliothèques de modèles utilisent une nouvelle fonction () pour accélérer la génération de modèles. C'est idéal pour les programmes dynamiques, mais il est risqué pour un texte malveillant.
Rapport
Le CSP peut bloquer les ressources non fiables du côté serveur, ce qui est très utile pour les utilisateurs, mais il est très utile pour nous d'obtenir diverses notifications envoyées au serveur, afin que nous puissions identifier et réparer toutes les injections de script malveillantes. À cette fin, vous pouvez demander au navigateur d'envoyer un rapport d'interception au format JSON à une adresse via la directive Report-Uri.
Contenu-Sécurité-Policy: par défaut-Src «self»; ...; report-uri / my_amazing_csp_report_parser;
Le rapport ressemblera à ceci:
{
CSP-Report: {
Document-Uri:,
référent:,
Bloqué-Uri:,
violent-directif: script-src 'self' https://apis.google.com,
Police originale: script-src 'self' https://apis.google.com; Rapport-Uri
}
}
Les informations qui y sont contenues vous aideront à identifier la situation de blocage, y compris le document-URI qui se produit, le référent de page, la ressource qui viole la politique de la page, la directive violée et la politique originale de tout le contenu de la page.
Utilisation réaliste
CSP est désormais disponible sur Chrome 16+ et Firefox 4+ Browsers, et il devrait recevoir un support limité sur IE10. Safari n'est pas encore pris en charge, mais la construction de Nightly est disponible, il est donc prévu que Safari soit pris en charge dans l'itération ci-dessous.
Examinons certains cas d'utilisation couramment utilisés ci-dessous:
Cas réel 1: widget des médias sociaux
Le bouton Google +1 comprend des scripts à partir de https://apis.google.com, ainsi que des iframes intégrés à partir de https://plusone.google.com. Votre politique doit inclure ces sources pour utiliser le bouton Google + 1. La stratégie la plus simple est le script-src https://apis.google.com; frame-src https://plusone.google.com. Vous devez également vous assurer que les fragments JS fournis par Google sont stockés dans des fichiers JS externes.
Il existe de nombreuses solutions d'implémentation pour le bouton Like Facebook. Je vous recommande de vous en tenir à la version IFRAME car il reste bien isolé du reste de votre site. Cela nécessite l'utilisation de la directive Https://facebook.com Frame-Src. Veuillez noter que par défaut, le code IFRAME fourni par Facebook utilise le chemin relatif //facebook.com. Veuillez modifier ce code sur https://facebook.com. Il n'est pas nécessaire que HTTP ne soit pas utilisé.
Le bouton Tweet de Twitter dépend du script et du cadre, à la fois à partir de https://platform.twitter.com (Twitter fournit une URL relative par défaut, veuillez modifier le code lors de la copie pour le spécifier en tant que HTTPS).
D'autres plates-formes ont des situations similaires et peuvent être résolues de manière similaire. Je recommande de définir la défaut de défaut à nulle, puis de regarder la console pour vérifier les ressources dont vous devez utiliser pour vous assurer que le widget fonctionne correctement.
L'utilisation de plusieurs widgets est très simple: fusionnez simplement toutes les directives de politique et n'oubliez pas de mettre ensemble les paramètres de la même directive. Si vous souhaitez utiliser les trois widgets ci-dessus, la stratégie ressemblera à ceci:
script-src https://apis.google.com https://platform.twitter.com; frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com
Cas réel 2: Défense
Supposons que vous visitez un site Web bancaire et que vous souhaitiez vous assurer que seules les ressources dont vous avez besoin sont chargées. Dans ce cas, commencez à définir une autorisation par défaut pour tout bloquer (par défaut-Src «Aucun») et construire la stratégie à partir de zéro.
Par exemple, un site Web bancaire doit charger des images, des styles et des scripts du CDN à partir de https://cdn.mybank.net, et de se connecter à https://api.mybank.com/ via XHR pour extraire diverses données. Il doit également utiliser un cadre, mais les cadres proviennent tous de pages locales non tiers. Il n'y a pas de flash, de polices et d'autres contenus sur le site Web. Dans ce cas, nous pouvons envoyer l'en-tête CSP le plus strict est:
Content-Security-Policy: Default-Src 'Aucun'; script-src https://cdn.mybank.net; Style-Src https://cdn.mybank.net; IMG-Src https://cdn.mybank.net; Connect-Src https://api.mybank.com; trame-src «soi»
Cas réel 3: Utilisez uniquement SSL
Un administrateur du forum de bague de mariage veut que toutes les ressources soient chargées de manière sûre, mais ne veulent pas vraiment écrire trop de code; La réécriture d'un grand nombre de scripts et styles en ligne du forum tiers dépasse sa capacité. La stratégie suivante sera donc très utile:
Content-Securecurity-Policy: Default-Src https:; script-src https: 'danget-in-inline'; Style-SRC HTTPS: «Discut-in-inline»
Bien que le SRC par défaut spécifie HTTPS, les scripts et les styles ne sont pas automatiquement hérités. Chaque directive remplacera complètement le type de ressource par défaut.
avenir
Le groupe de travail sur la sécurité des applications Web du W3C élabore des détails sur les spécifications de la politique de sécurité du contenu. La version 1.0 entrera dans l'étape de révision finale, qui est très proche de ce qui est décrit dans cet article. Le groupe de messagerie public-webappsec @ discute de la version 1.1, et les fabricants de navigateurs travaillent également dur pour consolider et améliorer la mise en œuvre du CSP.
CSP 1.1 a des choses intéressantes sur le tableau artistique qui valent la peine d'être inscrites séparément:
Ajout de politiques via des balises Meta: la façon préférée de définir CSP est les en-têtes HTTP, ce qui est très utile, mais il sera plus direct via des balises ou des scripts, mais il n'a pas encore été finalisé. WebKit a implémenté la fonctionnalité du paramètre d'autorisation via des éléments META, vous pouvez donc maintenant essayer les paramètres suivants dans Chrome: Ajouter <MetAhttp-Equiv = X-Webkit-CSP Content = [Policy Goes ICI]> à l'en-tête du document.
Vous pouvez même ajouter des politiques via des scripts lors de l'exécution.
API DOM: Si cette fonctionnalité est ajoutée à la prochaine itération de CSP, vous pouvez interroger la politique de sécurité actuelle de la page via JavaScript et l'ajuster en fonction de différentes situations. Par exemple, si evv () est disponible, votre implémentation de code peut être légèrement différente. Ceci est très utile pour l'auteur du framework JS; Et la spécification API est encore très incertaine, vous pouvez trouver la dernière itération de la section d'interface de script du projet de spécification.
Nouvelles directives: de nombreuses nouvelles directives sont en discussion, y compris le Script-Nonce: les scripts en ligne ne peuvent être utilisés que si les éléments de script explicitement spécifiés sont utilisés; Plugin-Types: Cela limitera le type de plugin; Form-action: permettez que le formulaire soit soumis à une source spécifique uniquement.
Si vous êtes intéressé par les discussions sur ces futures fonctionnalités, vous pouvez lire les archives de la liste de diffusion ou l'ajouter à la liste de diffusion.
Cet article est traduit de:
Extrait de: le blog de Jiang Yujie