Appliquer une stratégie de sécurité du contenu pour ASP.NET Core Blazor

Cet article explique comment utiliser une stratégie de sécurité de contenu (CSP) avec des applications ASP.NET Core Blazor pour vous protéger contre les attaques de scripting inter-site (XSS).

Le scripting inter-site (XSS) est une vulnérabilité de sécurité dans laquelle un cyberattaquant place un ou plusieurs scripts côté client malveillants dans le contenu rendu d’une application. Un stratégie de sécurité du contenu permet de se protéger contre les attaques XSS en informant le navigateur de la validité des :

• Sources du contenu chargé, y compris les scripts, les feuilles de style, les images et les plug-ins.
• Actions effectuées par une page, spécifiant les cibles d’URL autorisées des formulaires.

Pour appliquer une stratégie de sécurité du contenu à une application, le développeur spécifie plusieurs directives de sécurité du contenu CSP dans un ou plusieurs en-têtes Content-Security-Policy ou balises <meta>. Pour obtenir des conseils sur l’application d’un fournisseur de solutions Cloud à une application en code C# au démarrage, consultez Démarrage de ASP.NET Core Blazor.

Les stratégies sont évaluées par le navigateur pendant le chargement d’une page. Le navigateur inspecte les sources de la page et détermine si elles répondent aux exigences des directives de sécurité du contenu. Lorsque les directives de stratégie ne sont pas respectées pour une ressource, le navigateur ne charge pas cette ressource. Par exemple, imaginez une stratégie qui n’autorise pas les scripts tiers. Lorsqu’une page contient une balise <script> avec une origine tierce dans l’attribut src, le navigateur empêche le chargement du script.

La stratégie de sécurité du contenu est prise en charge dans la plupart des navigateurs mobiles et de bureau modernes, notamment Chrome, Edge, Firefox, Opera et Safari. La stratégie de sécurité du contenu est recommandée pour les applications Blazor.

Directives de stratégie

Spécifiez au minimum les directives et les sources suivantes pour les applications Blazor. Ajoutez des directives et des sources supplémentaires, si nécessaire. Les directives suivantes sont utilisées dans la section Appliquer la stratégie de cet article, où sont fournis des exemples de stratégies de sécurité pour les applications Blazor :

• base-uri : limite les URL de la balise <base> d’une page. Spécifiez self pour indiquer que l’origine de l’application, y compris le schéma et le numéro de port, est une source valide.
• default-src : indique une solution de repli pour les directives sources qui ne sont pas explicitement spécifiées par la stratégie. Spécifiez self pour indiquer que l’origine de l’application, y compris le schéma et le numéro de port, est une source valide.
• img-src : indique des sources valides des images.
  • Spécifiez data: pour autoriser le chargement d’images à partir des URL data:.
  • Spécifiez https: pour autoriser le chargement d’images à partir de points de terminaison HTTPS.
• object-src : indique des sources valides des balises <object>, <embed> et <applet>. Spécifiez none pour empêcher toutes les sources d’URL.
• script-src : indique des sources valides des scripts.
  • Spécifiez self pour indiquer que l’origine de l’application, y compris le schéma et le numéro de port, est une source valide.
  • Dans une application Blazor côté client :
    • Spécifiez wasm-unsafe-eval pour autoriser le runtime Mono Blazor côté client à fonctionner.
    • Spécifiez les hachages supplémentaires pour autoriser le chargement de vos scripts hors infrastructure obligatoires.
  • Dans une application Blazor côté serveur, spécifiez les hachages pour autoriser le chargement des scripts obligatoires.
• style-src : indique des sources valides des feuilles de style.
  • Spécifiez self pour indiquer que l’origine de l’application, y compris le schéma et le numéro de port, est une source valide.
  • Si l’application utilise des styles intralignes, spécifiez unsafe-inline pour autoriser l’utilisation de vos styles intralignes.
• upgrade-insecure-requests : indique que les URL de contenu provenant de sources non sécurisées (HTTP) doivent être acquises de manière sécurisée via HTTPS.

Les directives précédentes sont prises en charge par tous les navigateurs, à l’exception de Microsoft Internet Explorer.

Pour obtenir des hachages SHA pour des scripts intralignes supplémentaires :

• Appliquez la stratégie de sécurité du contenu indiquée dans la section Appliquer la stratégie.
• Accédez à la console des outils de développement du navigateur lors de l’exécution locale de l’application. Le navigateur calcule et affiche des hachages des scripts bloqués lorsqu’un en-tête de fournisseur de solutions Cloud ou une balise meta est présent(e).
• Copiez les hachages fournis par le navigateur dans les sources script-src. Utilisez des guillemets simples autour de chaque hachage.

Pour obtenir une matrice de prise en charge du navigateur de niveau 2 de stratégie de sécurité du contenu, consultez Puis-je utiliser : stratégie de sécurité du contenu niveau 2.

Application de la stratégie

Utilisez une balise <meta> pour appliquer la stratégie :

• Définissez la valeur de l’attribut http-equiv sur Content-Security-Policy.
• Placez les directives dans la valeur de l’attribut content . Des directives distinctes avec un point-virgule (;).
• Placez toujours la balise meta dans le<head> contenu.

Les sections suivantes présentent des exemples de stratégie. Ces exemples sont versionnés avec cet article pour chaque édition de Blazor. Pour utiliser une version appropriée pour votre édition, sélectionnez la version du document à l’aide du sélecteur de liste déroulante Version sur cette page web.

Applications Blazor côté serveur

Dans le <head> contenu, appliquez les directives décrites dans la section Directives de stratégie :

<meta http-equiv="Content-Security-Policy" 
      content="base-uri 'self';
               default-src 'self';
               img-src data: https:;
               object-src 'none';
               script-src 'self';
               style-src 'self';
               upgrade-insecure-requests;">

Ajoutez les hachages supplémentaires script-src et style-src selon les besoins de l’application. Pendant le développement, utilisez un outil en ligne ou des outils de développement de navigateur pour calculer les hachages pour vous. Par exemple, l’erreur suivante dans la console des outils de navigateur signale le hachage d’un script obligatoire non couvert par la stratégie :

Refus d’exécuter un script intraligne parce qu’il enfreint la directive de stratégie de sécurité du contenu suivante : « ... ». Le mot clé « unsafe-inline », un hachage (« sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA= ») ou un nonce (« nonce-... ») est obligatoire pour activer l’exécution intraligne.

Le script particulier associé à l’erreur s’affiche dans la console après l’erreur.

Applications Blazor côté client

Dans le <head> contenu, appliquez les directives décrites dans la section Directives de stratégie :

<meta http-equiv="Content-Security-Policy" 
      content="base-uri 'self';
               default-src 'self';
               img-src data: https:;
               object-src 'none';
               script-src 'self'
                          'wasm-unsafe-eval';
               style-src 'self';
               upgrade-insecure-requests;">

Ajoutez les hachages supplémentaires script-src et style-src selon les besoins de l’application. Pendant le développement, utilisez un outil en ligne ou des outils de développement de navigateur pour calculer les hachages pour vous. Par exemple, l’erreur suivante dans la console des outils de navigateur signale le hachage d’un script obligatoire non couvert par la stratégie :

Refus d’exécuter un script intraligne parce qu’il enfreint la directive de stratégie de sécurité du contenu suivante : « ... ». Le mot clé « unsafe-inline », un hachage (« sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA= ») ou un nonce (« nonce-... ») est obligatoire pour activer l’exécution intraligne.

Le script particulier associé à l’erreur s’affiche dans la console après l’erreur.

Appliquer une stratégie de sécurité de contenu (CSP, Content Security Policy) dans des environnements hors Development

Lorsqu’une CSP est appliquée au contenu <head> d’une application Blazor, elle interfère avec les tests locaux dans l’environnement de Development. Par exemple, le lien du navigateur et le script d’actualisation du navigateur ne peuvent pas être chargés. Les exemples suivants montrent comment appliquer la balise <meta> de la CSP dans des environnements hors Development.

Remarque

Les exemples de cette section n’affichent pas la balise <meta> complète pour les CSP. Les balises <meta> complètes se trouvent dans les sous-sections de la section Appliquer la stratégie plus haut dans cet article.

Trois approches générales sont disponibles :

• Appliquez la CSP via le composant App, qui permet d’appliquer la CSP à toutes les layouts de l’application.
• Si vous devez appliquer des CSP à différentes zones de l’application, par exemple une CSP personnalisée pour les pages d’administration uniquement, appliquez la CSP par layout à l’aide de la balise <HeadContent>. Pour une efficacité totale, chaque fichier de layout d’application doit adopter cette approche.
• Le service d’hébergement ou le serveur peut fournir une CSP via un en-tête Content-Security-Policy ajouté aux réponses sortantes d’une application. Étant donné que cette approche varie en fonction du service d’hébergement ou du serveur, elle n’est pas traitée dans les exemples suivants. Si vous souhaitez adopter cette approche, consultez la documentation de votre fournisseur de services d’hébergement ou votre serveur.

Approches Blazor Web App

Dans le composant App (Components/App.razor), injectez IHostEnvironment :

@inject IHostEnvironment Env

Dans le contenu <head> du composant App, appliquez la CSP quand elle n’est pas dans l’environnement de Development :

@if (!Env.IsDevelopment())
{
    <meta ...>
}

Vous pouvez également appliquer des CSP par layout dans le dossier Components/Layout, comme l’illustre l’exemple suivant. Assurez-vous que chaque layout spécifie une CSP.

@inject IHostEnvironment Env

@if (!Env.IsDevelopment())
{
    <HeadContent>
        <meta ...>
    </HeadContent>
}

Approches d’application Blazor WebAssembly

Dans le composant App (App.razor), injectez IWebAssemblyHostEnvironment :

@using Microsoft.AspNetCore.Components.WebAssembly.Hosting
@inject IWebAssemblyHostEnvironment Env

Dans le contenu <head> du composant App, appliquez la CSP quand elle n’est pas dans l’environnement de Development :

@if (!Env.IsDevelopment())
{
    <HeadContent>
        <meta ...>
    </HeadContent>
}

Vous pouvez également utiliser le code précédent, mais appliquer des CSP par layout dans le dossier Layout. Assurez-vous que chaque layout spécifie une CSP.

Limitations des balises meta

Une stratégie de balise <meta> ne prend pas en charge les directives suivantes :

• frame-ancestors
• report-to
• report-uri
• sandbox

Pour prendre en charge les directives précédentes, utilisez un en-tête nommé Content-Security-Policy. La chaîne de directive est la valeur de l’en-tête.

Tester une stratégie et recevoir des rapports de violation

Le test permet de vérifier que les scripts tiers ne sont pas bloqués par inadvertance lors de la création d’une stratégie initiale.

Pour tester une stratégie sur une certaine période sans appliquer les directives de stratégie, définissez l’attribut <meta> de la balise http-equiv ou le nom d’en-tête d’une stratégie basée sur l’en-tête sur Content-Security-Policy-Report-Only. Les rapports d’échec sont envoyés sous forme de documents JSON vers une URL spécifiée. Pour plus d’informations, consultez Documentation web sur notification de réception du message : rapports de stratégie de sécurité du contenu uniquement.

Pour la création de rapports sur les violations pendant qu’une stratégie est active, consultez les articles suivants :

• report-to
• report-uri

Bien que l’utilisation de report-uri ne soit plus recommandée, les deux directives doivent être utilisées jusqu’à ce que report-to soit pris en charge par tous les principaux navigateurs. N’utilisez pas report-uri exclusivement, car la prise en charge de report-uri peut être supprimée des navigateurs à tout moment. Supprimez la prise en charge de report-uri dans vos stratégies lorsque report-to est entièrement pris en charge. Pour suivre l’adoption de report-to, consultez Puis-je utiliser : report-to.

Testez et mettez à jour la stratégie d’une application à chaque édition.

Résoudre des problèmes

• Les erreurs s’affichent dans la console des outils de développement du navigateur. Les navigateurs fournissent des informations sur :
  • Les éléments qui ne sont pas conformes à la stratégie.
  • Comment modifier la stratégie pour autoriser un élément bloqué.
• Une stratégie n’est totalement efficace que lorsque le navigateur du client prend en charge toutes les directives comprises. Pour obtenir une matrice de prise en charge du navigateur actuel, consultez Puis-je utiliser : stratégie de sécurité du contenu.

Ressources supplémentaires

• Appliquer une stratégie de sécurité du contenu dans le code C# au démarrage
• MDN web docs : stratégie de sécurité du contenu (CSP)
• MDN web docs : en-tête de réponse Content-Security-Policy
• Stratégie de sécurité du contenu de niveau 2
• Évaluateur de stratégie de sécurité du contenu de Google