Gestion de la sécurité du contenu dans les applications Telerik ASP.NET Core

Le nouveau modèle de projet Telerik UI pour ASP.NET Core vous offre une meilleure protection : il explique comment faire fonctionner CSP pour vous.

Disons, par exemple, que vous avez créé avec plaisir des applications ASP.NET Core à l’aide du Extensions de progrès Telerik Visual Studio pour générer le point de départ de vos projets. Tout se passe bien jusqu’à ce que vous commenciez à créer une nouvelle application, sûr de savoir ce que vous faites et comment tout cela fonctionne… sauf que cette fois, lorsque vous démarrez votre application, ce n’est pas vraiment le cas. travail.

Si les symptômes sont que les images ne s’affichent pas, que les feuilles de style ne sont pas appliquées, que la vidéo n’est pas lue ou que les requêtes de service Web ne sont pas émises, le problème peut provenir d’une politique de sécurité du contenu (CSP).

Pour confirmer si le problème vient de CSP, appuyez simplement sur F12 dans votre navigateur, vérifiez les messages dans la fenêtre de la console et voyez si vous trouvez un message comme celui-ci (les astérisques représentent le contenu du message qui varie en fonction du problème) :

Refusé de charger le https:// car il viole la directive suivante de la politique de sécurité du contenu.

Si vous utilisez le modèle Telerik par défaut comme point de départ de votre projet, le coupable est un <meta> balise qui est automatiquement incluse dans le fichier Layout.cshtml du projet (le fichier est la base par défaut pour toutes vos vues). Voici la version actuelle de cette balise, formatée pour la rendre plus facile à lire :

<meta http-equiv="Content-Security-Policy"
  content="default-src 'self';
  
    img-src 'self'
      data:;

    script-src 'self'
      https://kendo.cdn.telerik.com
      https://code.jquery.com/
      https://cdn.kendostatic.com
      https://unpkg.com
      https://cdn.jsdelivr.net 'nonce-Telerik-Examples';
 
    style-src 'self'
      https://kendo.cdn.telerik.com
      https://unpkg.com
      https://cdn.jsdelivr.net;

    font-src 'self'  
      https://unpkg.com;

    connect-src 'self'
      ws:
      http:;" />

Vous pourriez faire disparaître votre erreur en supprimant simplement la balise, mais c’est probablement une erreur. Cette politique de sécurité du contenu (CSP) <meta> La balise aide à protéger contre les attaques par injection de code et par cross-site-scripting (XSS).

Fondamentalement, ce CSP aide à protéger votre projet en limitant les sources où votre page peut récupérer des scripts, des feuilles de style et des images (ou toute autre ressource) aux sources répertoriées dans le <meta> étiqueter.

Cependant, cela signifie également que si vous téléchargez des ressources à partir de quelque chose que Progress Telerik ne peut pas prendre en compte (le site de feuilles de style de votre organisation, par exemple), votre application ne fonctionnera pas.

Pour y remédier, vous devez d’abord savoir lire le CSP ajouté dans le <meta> étiqueter.

Un CSP comme celui ajouté dans le <meta> La balise est divisée en plusieurs sections (appelées directives), séparées par des points-virgules. Une directive commence par le nom de la directive et est suivie d’une série de sources délimitées par des espaces.

La directive clé est default-src qui, sauf remplacement dans d’autres directives, spécifie d’où la page peut télécharger des ressources (dans CSP, default-src est considérée comme une solution de secours lorsque d’autres directives ne sont pas fournies). Voici le default-src directive du <meta> balise, répertoriant une source : le mot-clé 'self':

default-src 'self';

Le 'self' Le mot-clé limite les téléchargements aux ressources du même domaine à partir duquel votre page a été téléchargée. Les autres directives remplacent cette liste par défaut pour des types spécifiques de contenu afin d’ajouter des sources supplémentaires.

Le img-src La directive, par exemple, vous permet de spécifier les sites que vous souhaitez activer pour le téléchargement d’images. Le <meta> la balise dans votre projet généré par Telerik utilise 'self' pour télécharger des images du même domaine que la page, mais ajoute également n’importe quelle image en utilisant un URI commençant par data. (Les données : URI vous permettent d’intégrer des fichiers codés en base64 directement dans votre page plutôt que d’avoir à les télécharger séparément.)

img-src 'self'
  data:;

Les autres directives précisent les sources pour :

• Téléchargement de fichiers JavaScript : le domaine de votre page, le site Telerik, ainsi que certains sites publics et de réseaux de diffusion de contenu comme unpkg.com (script-src). Le nonce Le mot-clé amène le serveur à générer une clé aléatoire unique qui est incluse dans le téléchargement et vérifiée par le navigateur pour vérifier que le script provient du serveur demandé :

script-src 'self'
  https://kendo.cdn.telerik.com
  …
  https://cdn.jsdelivr.net 'nonce-Telerik-Examples';

• Téléchargement de feuilles de style : Même type de sites qu’avec les fichiers script (style-src)
• Téléchargement de polices : le domaine de votre page et unpkg.com (font-src)
• Appel de WebSockets et de services Web : requêtes vers le domaine de votre page ainsi que toutes les requêtes WebSocket et requêtes HTTP/HTTPS (connect-src)

Le résultat de ce CPS est que chaque source pas dans ces listes est bloqué, ce qui inclut les feuilles de style, les images, les fichiers audio/vidéo, etc. qui ne proviennent pas du domaine de votre application. Faire fonctionner votre application revient donc à étendre ces listes pour inclure ces autres sources.

Remarque : lors de la lecture ou de la modification d’un CSP, autoriser HTTP autorise également HTTPS (et vice versa). Un img-src directive qui comprend http:phvis.compar exemple, permettrait toujours à cette balise d’image de télécharger son image via HTTPS :

<img src=https://phvis.com/SomePictureOnPetersSite.jpg />

En règle générale, vous rencontrerez un problème CSP parce que vous accédez à une ressource depuis un endroit autre que le domaine de votre page (par exemple, un site d’images/feuilles de style partagées ou une vidéo d’un site de streaming). Lorsque vous rencontrez ce problème, vous avez deux manières de le résoudre :

• Prolonger le default-src directive pour inclure l’autre site. Cela est logique si vous téléchargez plusieurs ressources à partir de ce site et avez confiance en sa sécurité (un site d’entreprise central avec des ressources à utiliser sur toutes les pages de votre organisation).
• Étendez la directive pour la ressource spécifique qui est bloquée (par exemple, en ajoutant l’URL où sont conservées les feuilles de style/images de votre organisation).

Cette dernière option peut inclure l’ajout d’une nouvelle directive si la ressource ne fait pas partie des types déjà répertoriés dans le CSP (par exemple, si la ressource bloquée est un fichier vidéo ou audio sur un autre site). Pour un fichier vidéo ou audio par exemple, vous devez ajouter le media-src directive au CSP (voir la liste de directives pour d’autres types de ressources).

D’un autre côté, si votre organisation nécessite quelque chose de plus restrictif (la stratégie « Bloquer tout, autoriser certains ») ou si vous préférez quelque chose de plus flexible (la stratégie « Autoriser tout, contrôler certains »), vous souhaiterez peut-être échanger un CSP complètement différent.

Définir une politique de sécurité du contenu

Si vous souhaitez aller au-delà de la configuration de pages CSP pour des pages individuelles, vous pouvez configurer votre serveur Web pour qu’il renvoie un CSP comme l’un des en-têtes de réponse pour toute demande. Si vous le faites, vous disposerez également de plus d’options que celles disponibles en utilisant le <meta> étiqueter. Je vais continuer avec le <meta> étiquette, cependant.

Le point de départ de votre CSP est une politique sans contenu : une politique qui ne spécifie rien autorise tout. Continuer à utiliser le <meta> tag comme exemple, une politique qui autorise tout ressemblerait à ceci :

<meta http-equiv="Content-Security-Policy" />

Ou, plus explicitement :

<meta http-equiv="Content-Security-Policy" />
  content="" />

À partir de là, vous pouvez mettre en œuvre l’une des trois stratégies suivantes : « Autoriser tout, contrôler certains », « Tout bloquer, autoriser certains » ou « Autoriser certains, contrôler certains ».

Autoriser tout, contrôler certains

La mise en œuvre d’une stratégie « Autoriser tout » commence par l’omission du default-src directive qui fournit la solution de repli pour toute directive omise. Sans un default-srctoute directive que vous ne le faites pas fournir permet tout.

À partir de là, vous contrôlez uniquement les ressources qui vous intéressent en incluant des directives pour ces ressources. Cet exemple bloque uniquement les scripts (ils doivent provenir du domaine de la page ou de mon site) tout en autorisant tout autre type de ressource :

<meta http-equiv="Content-Security-Policy"
  content="script-src 'self'
    http://phvis.com" />

Cette stratégie est logique lorsque vous estimez que vous ne devez contrôler qu’un petit nombre de ressources. C’est la stratégie la plus risquée (avez-vous contrôlé toutes les bonnes ressources ?) mais elle aura le moins d’impact sur vos applications.

Bloquer tout, autoriser certains

Une autre stratégie consiste à tout bloquer, puis à autoriser des ressources spécifiques. Avec cette stratégie, votre point de départ est de fournir à un CSP un default-src sans valeur, cela bloquera toutes les ressources :

<meta http-equiv="Content-Security-Policy"
  content="default-src;" />

Si vous voulez être plus explicite, vous pouvez utiliser 'none' pour préciser que vous bloquez tout :

<meta http-equiv="Content-Security-Policy"
  content="default-src 'none';" />

Vous pouvez désormais autoriser de manière sélective le téléchargement de certaines ressources. Cet exemple laisse entrer les images du domaine de la page et de mon site mais bloque toujours les feuilles de style, l’accès WebSocket, les requêtes de service Web et tout ce qui n’est pas mentionné dans ce CSP :

<meta http-equiv="Content-Security-Policy"
  content="default-src 'none';"
  img-src  'self'
    http://phvis.com" />

C’est probablement la stratégie la plus sûre, mais elle aura le plus grand impact sur vos applications (pour être plus exact : davantage d’applications cesseront de fonctionner). Cela entraînera également la plus longue liste de CSP et les efforts de maintenance, car vous devrez continuer à ajouter plus de directives à mesure que vos sites accèdent à une plus grande variété de ressources à partir d’une liste de sources plus longue.

Autoriser certains, contrôler certains

La troisième stratégie consiste à utiliser default-src pour spécifier une source commune pour toutes les ressources que vous autoriserez (généralement, c’est juste 'self'—le domaine de votre page). Vous ajoutez ensuite des directives pour des ressources spécifiques qui nécessitent quelque chose de plus. C’est la stratégie que Telerik a utilisée dans son CSP.

Lorsque vous ajoutez ces autres directives, n’oubliez pas que ces nouvelles directives ne s’étendent pas default-src mais au lieu de cela, remplacez-le. Essentiellement, cela signifie que la plupart/toutes vos directives supplémentaires commenceront par ce que vous avez dans le default-src directif.

Cet exemple permet de télécharger n’importe quelle ressource du domaine de ma page et de mon site, à l’exception des images. Pour les images, cette politique autorise les images du domaine de la page, de mon site et du site Telerik :

<meta http-equiv="Content-Security-Policy"
  content="default-src 'self'
    http://phvis.com;

    img-src 'self'
      http://phvis.com
      http://Telerik.com" />

Cette stratégie est essentiellement un compromis entre les deux autres : en fournissant une solution de repli default-src qui autorise les ressources de vos sites « sécurisés », cela réduit le nombre de directives que vous devrez ajouter. Il vous suffira désormais d’ajouter des directives dans lesquelles vous devrez spécifier un ensemble de ressources différent ou plus long que votre liste par défaut de sites « sûrs ».

Donc : Oui, CSP peut être ennuyeux. Mais CSP vous aide à vous protéger contre les attaques. Et, compte tenu de l’embarras que représente le fait de découvrir votre site dégradé ou piraté, cela vaut probablement la peine de mettre en œuvre une stratégie qui vous évite d’expliquer comment cela s’est produit.

En savoir plus sur Progrès Interface utilisateur Telerik pour ASP.NET Core et essayez-le vous-même, gratuitement pendant 30 jours.