Amélioration de la sécurité Web avec la politique de sécurité du contenu

Politique de sécurité du contenu (CSP): un guide complet de la sécurité du Web

La politique de sécurité du contenu (CSP) est un mécanisme de sécurité crucial de sauvegarde des sites Web contre les attaques d'injection de contenu, principalement des scripts inter-sites (XSS). Cette politique déclarative permet aux développeurs de créer une liste blanche d'origine de ressources de confiance, contrôlant comment le navigateur charge les ressources, utilise des styles et scripts en ligne et gère l'évaluation dynamique JavaScript (par exemple, en utilisant eval()). Toute tentative de chargement des ressources de l'extérieur de cette liste blanche est bloquée.

Concepts clés:

• Approche en liste blanche: CSP fonctionne en définissant des sources autorisées, en bloquant tout le reste.
• HTTP En-tête de livraison: La politique est mise en œuvre via l'en-tête Content-Security-Policy http.
• Contrôle basé sur la directive: L'en-tête contient des directives spécifiant les domaines autorisés et restreignant l'exécution JavaScript pour empêcher les attaques d'injection.
• Rapports de violation: Les violations CSP des journaux de directifs de la directive, inestimables pour les environnements de production. Cela envoie un rapport JSON détaillant la violation à une URL spécifiée. report-uri

Comment fonctionne CSP:

CSP, une recommandation candidate W3C, utilise l'en-tête

pour livrer des directives. Les directives clés incluent: Content-Security-Policy, default-src, script-src, object-src, style-src, img-src, media-src, frame-src et font-src. connect-src agit comme un repli pour les directives non spécifiées. default-src

Les directives suivent un modèle cohérent:

• : fait référence au domaine actuel. self
Liste des URL: URL séparés dans l'espace spécifiant les origines autorisées.
• : interdit de charger des ressources pour une directive donnée (par exemple, none bloque les plugins). object-src 'none'

Un CSP de base n'accordez aux ressources que du domaine actuel:

<code>Content-Security-Policy: default-src 'self';</code>

Toute tentative de chargement à partir d'un autre domaine est bloquée, avec un message de console. Le CSP restreint intrinsèquement les scripts en ligne et l'évaluation du code dynamique, atténuant considérablement les risques d'injection.

Bien que les domaines soient spécifiés, les chemins ne sont pas actuellement pris en charge. Les caractères génériques (

), cependant, permettent l'inclusion du sous-domaine (par exemple, ` .mycdn.com`). Chaque directive nécessite une liste explicite de domaine / sous-domaine; Ils n'héritent pas des directives précédentes.

pour les URL de données, incluez data: dans la directive (par exemple, img-src 'data:'). unsafe-inline (pour script-src et style-src) Permet les balises en ligne <script></script> et <style></style>, et unsafe-eval (pour script-src) permet une évaluation du code dynamique. Les deux utilisent des politiques opt-in; leur omettre applique des restrictions.

Compatibilité du navigateur:

CSP 1.0 bénéficie d'un large support de navigateur, avec des versions d'anciennes explorateurs Internet ayant une compatibilité limitée.

Surveillance des violations avec report-uri:

Alors que le développement utilise la journalisation de la console de navigateur, les environnements de production bénéficient de report-uri. Cela envoie des demandes de poste HTTP contenant les détails de violation (au format JSON) à une URL spécifiée.

Exemple:

<code>Content-Security-Policy: default-src 'self';</code>

Une violation (par exemple, le chargement de www.google-analytics.com) génère un rapport JSON envoyé au report-uri.

Content-Security-Policy-Report-Only En-tête:

Pour les tests, utilisez Content-Security-Policy-Report-Only. Cela rapporte des violations sans bloquer les ressources, autorisant le raffinement des politiques sans perturbation du site. Les deux en-têtes peuvent être utilisés simultanément.

Implémentation de CSP:

CSP est défini via l'en-tête HTTP. La configuration du serveur (apache, iis, nginx) ou méthodes programmatiques (PHP header(), Node.js's setHeader()) peut être utilisée.

Exemples du monde réel:

Facebook et Twitter démontrent diverses implémentations CSP, en utilisant les jarquettes et des allocations de domaine spécifiques.

CSP Niveau 2 Améliorations:

CSP Level 2 introduit de nouvelles directives (base-uri, child-src, form-action, frame-ancestors, plugin-types), des rapports améliorés et une protection non basée sur le hachage pour les scripts et styles en ligne.

Protection non basée sur les non -ce:

Un nonce généré de manière aléatoire est inclus à la fois dans l'en-tête CSP et la balise de script en ligne.

Protection basée sur le hachage:

Le serveur calcule le hachage du bloc de script / style, inclus dans l'en-tête CSP. Le navigateur vérifie ce hachage avant l'exécution.

Conclusion:

CSP améliore considérablement la sécurité Web en contrôlant le chargement des ressources. report-uri facilite la surveillance et le niveau 2 introduit des raffinements supplémentaires. La mise en œuvre du CSP est une étape essentielle dans la création d'applications Web robustes et sécurisées.

(Remarque: Les espaces réservés d'image restent inchangés comme demandé.)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!