Réduire la latence, pas la sécurité

La politique de sécurité du contenu (CSP) est une fonction de sécurité mise en œuvre dans les navigateurs web pour protéger les sites web et les applications web contre divers types d'attaques, telles que les attaques de type cross-site scripting (XSS) et les attaques par injection de données. La PSC contrôle et limite les sources de différents types de contenu que vous pouvez charger ou exécuter sur une page web. Ces types de contenu sont les suivants

• Scripts
• Feuilles de style
• Images

Dans ce billet, nous allons tout d'abord examiner le fonctionnement du CSP. Nous verrons qu'une utilisation plus efficace et plus dynamique du CSP inclut certains calculs qui doivent être effectués sur le serveur. Cependant, il est possible de déplacer ce calcul à la périphérie, ce qui réduit la latence et garantit une expérience optimale pour l'utilisateur final. Nous verrons également comment cette solution de calcul à la périphérie peut fonctionner.

Êtes-vous prêt à vous lancer ? Commençons par comprendre le fonctionnement du CSP.

Comment fonctionne la DSP

Un CSP est généralement défini côté serveur par l'ajout d'un élément Content-Security-Policy à votre réponse HTTP. Il est envoyé par le serveur web à un utilisateur qui demande une page web. Cet en-tête spécifie les règles que le navigateur doit suivre lors du chargement et de l'exécution du contenu de la page.

Exemples de réglage de la Content-Security-Policy en-tête

Imaginons que vous travailliez avec Express à l'adresse Node.js et que vous définissiez votre en-tête CSP de la manière suivante :

Si vous utilisiez Python avec Flask, le code ressemblerait à ceci :

Travailler avec des directives

Chaque en-tête CSP peut comporter plusieurs directives, et chaque directive peut avoir des valeurs adaptées au type de paramètre fourni. Ces directives définissent les règles de sécurité pour différents types de ressources. Par exemple, l'en-tête script-src spécifie les sources autorisées pour les feuilles de style.

Considérons l'en-tête CSP suivant :

Dans l'en-tête ci-dessus, nous voyons trois directives, chacune accompagnée de valeurs.

• Les default-src fixée à la directive 'self'spécifie que, par défaut, tout le contenu doit être chargé à partir de la même origine que la page elle-même.
• Les script-src permet aux scripts d'être chargés à partir de la même origine ('self') et la source externe spécifiée (https://static.example.com).
• Les style-src permet aux feuilles de style d'être chargées à partir de la même origine et autorise également les styles en ligne.

La liste des directives disponibles est en fait assez exhaustive. Elle peut être consultée ici. Les directives comprennent :

• font-src: Sources des polices chargées à l'aide de @font-face
• frame-src: Sources pour les contextes de navigation imbriqués chargés dans des éléments tels que <frame> et <iframe>
• img-src: Sources d'images et de favicons

Lier le PSC à l'HTML

Une fois que l'en-tête CSP est défini sur le serveur, le navigateur applique ces règles lors du chargement des ressources sur la page web.

Dans la source HTML, les développeurs peuvent ajouter des éléments (tels que des scripts ou des feuilles de style) en ligne ou en faisant référence à des ressources (de la même origine ou d'ailleurs). Le navigateur vérifie alors l'en-tête CSP pour s'assurer que ces ressources sont conformes aux règles définies. Si une ressource n'est pas autorisée par le CSP, le navigateur bloque son inclusion et son exécution.

Unique pour chaque demande

En raison de la manière dont les en-têtes CSP sont définis, ils sont généralement cohérents pour toutes les requêtes d'une page web donnée. Les détails et les directives pour chaque demande d'une page unique seront les mêmes pour chaque demande ultérieure de cette page.

Cela soulève une question intéressante : Comment traiter les styles et les scripts dynamiques en ligne ? Nous pourrions vouloir autoriser l'exécution de scripts et de styles inline spécifiques sans ouvrir la porte à l'inclusion de tous les scripts et styles inline.

Dans ce cas, il est possible d'introduire des valeurs nonce ou des hachages pour garantir que même si la source d'un script ou d'un style n'est pas explicitement répertoriée dans la DSP, il peut toujours être exécuté, tant qu'il correspond à la valeur nonce ou hachée spécifiée par l'en-tête de la DSP.

Ces valeurs de nonce ou de hachage peuvent changer à chaque demande, ce qui les rend uniques. Elles doivent donc être générées et gérées sur un serveur. Toutefois, ce n'est pas parce que ces nonces ou ces hachages doivent être exécutés sur un serveur qu'ils doivent nécessairement l'être sur le serveur principal de votre site. C'est là qu'intervient l'informatique de pointe.

Qu'est-ce que l'informatique de pointe ?

L'informatique en périphérie est essentiellement le concept selon lequel certains calculs peuvent être effectués à la périphérie de votre réseau, géographiquement proche de vos utilisateurs finaux. Il s'agit essentiellement d'un type d'informatique distribuée qui permet de se rapprocher des vitesses de calcul en temps réel, même sur l'internet, tout en réduisant la latence du réseau.

Avec l'informatique en périphérie, vous pourriez déplacer les préoccupations, en générant des nonces et des hachages pour vos en-têtes CSP plus près de vos utilisateurs finaux, réduisant ainsi le temps qu'ils doivent attendre pour que vous sécurisiez votre site.

Comment l'informatique de pointe peut aider les CSP

L'une des principales raisons pour lesquelles le CSP peut ralentir votre site est que les nonces dans les en-têtes peuvent entraîner des manques dans le cache, ce qui oblige le navigateur de votre client à aller jusqu'au serveur pour que votre site obtienne les en-têtes les plus récents générés correctement. Pour résoudre ce problème, vous pouvez mettre en œuvre un générateur de nonces CSP dynamique dans une instance périphérique. Cela vous permettra de vous assurer que votre mise en cache est toujours utile tout en maintenant la sécurité.

Les avantages de cette approche sont les suivants

• Temps de latence réduit: L'instance de calcul périphérique génère et insère le nonce dans la demande. Les demandes, maintenant que la nonce a été insérée, continuent de transiter vers le cache, ce qui évite d'avoir à appeler le serveur d'origine pour obtenir de nouvelles réponses à chaque fois qu'une demande est formulée.
• Sécurité distribuée: L'utilisation du calcul à la périphérie signifie que vous disposez d'une couche supplémentaire de sécurité avant même que les clients n'aient besoin d'interagir avec les serveurs principaux et le code d'application de votre système. Même en cas de vulnérabilité de l'application, le calcul à la périphérie qui calcule le nonce CSP fournit une couche de sécurité supplémentaire, ce qui vous aide à atténuer les problèmes potentiels.
• Facilité de maintenance: Si vous gérez la nonce dynamique pour l'en-tête CSP à la périphérie avec une approche sans serveur, cela simplifiera vos tâches de maintenance. En particulier, vous pouvez gérer les politiques CSP sans modifier le code de l'application. Vous pouvez également gérer ce type de changements à partir d'un système de contrôle central sans avoir à déployer de code spécial. Ces fonctions de calcul en périphérie peuvent également être utilisées par plusieurs applications indépendantes, ce qui permet de séparer les préoccupations des équipes spécifiques qui travaillent sur chaque application et permet aux professionnels de la sécurité de s'assurer que la génération de nonce est correcte.

Conclusion

Vous souhaitez en savoir plus sur l'utilisation de l'edge computing ? Si c'est le cas, jetez un coup d'œil à certains des produits présentés par Akamai. En particulier, les EdgeWorkers créent une expérience sans serveur qui peut faire exactement ce dont nous avons parlé dans cet article, sans la complexité de trouver comment déployer soi-même des serveurs à la périphérie de ses réseaux.

Si vous êtes prêt à l'essayer par vous-même, inscrivez-vous à un essai gratuit dès aujourd'hui! Il est temps de travailler à la sécurisation de votre site avec de meilleurs en-têtes CSP qui n'affectent pas votre système de mise en cache !