Entêtes HTTP

Article de magazine

Cet article est basé sur un article du Joomla! Community Magazine écrit par Brendan Hedges dans l'édition de mai 2022. Bien qu'écrit pour Joomla 4, le contenu s'applique également à Joomla 5.

Pour ceux qui trouvent ce sujet difficile à comprendre, il existe un article éclairant de Scott Helme sur Content Security Policy - An Introduction.

Le nouveau plugin En-têtes HTTP de Joomla pour J4

Suite à l'article du mois dernier sur la sécurité, les mots de passe et le plugin WebAuthn de Joomla, nous allons ce mois-ci examiner une autre fonctionnalité de sécurité de Joomla lancée avec J4. Il s'agit du plugin En-têtes HTTP qui fait désormais partie des fonctions du noyau de Joomla.

Internet ne cesse d'évoluer, et Joomla n'est jamais loin derrière. C'est pourquoi je l'ai choisi comme plateforme de développement web. Que votre site web soit une petite boutique familiale ou une plateforme e-commerce à part entière réalisant des millions de ventes, le framework Joomla a quelque chose pour tout le monde, et cherche toujours à mettre en œuvre de nouvelles technologies. Certaines sont même révolutionnaires.

L'introduction du plugin En-têtes HTTP dans le noyau de Joomla 4 est une avancée considérable pour aider à sécuriser votre site web contre les attaques et les activités malveillantes.

Ce plugin de sécurité système aide les propriétaires de sites à configurer facilement les en-têtes de sécurité HTTP depuis l'interface d'administration familière de Joomla, plutôt que de devoir fouiller dans le fichier htaccess ou d'autres fichiers de configuration. Ou, pire encore, dans le Cpanel de votre hébergeur web.

Regardez à quel point c'est compliqué à configurer dans Cpanel et dites-moi que vous ne ferez pas d'erreur ! Et cela en supposant que, une fois le framework installé dans Apache et les répertoires créés, vous connaissiez le format correct pour ajouter les en-têtes HTTP que vous souhaitez intégrer.

Combien de fois avez-vous essayé d'implémenter une commande htaccess, pour ensuite recharger votre site web et vous retrouver face à une erreur http500 ?

Le plus gros problème est que si le format de votre en-tête HTTP n'est pas parfait, vous casserez votre site.

Même dans ce cas, ce qui fonctionne pour un site web peut ne pas fonctionner pour un autre. Un bon exemple de cela est mon fichier htaccess et la façon dont je configure le navigateur pour charger une version https sans www de mon site web :

##www to non www and http to https mixin
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://mywebsite.co.uk%{REQUEST_URI} [R=301,L,NE]
##End www to non www and http to https mixin

Cela fonctionnait très bien avec mon précédent hébergeur. Mais lorsque j'ai changé d'hébergeur, cela a cessé de fonctionner. Allez comprendre !

Le code htaccess que je dois maintenant utiliser pour obtenir le même résultat ressemble à ceci :

##www to non www and http to https mixin
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
RewriteCond %{ENV:HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
##End www to non www and http to https mixin

Déroutant, n'est-ce pas ? Et si vous faites une seule erreur dans le formatage, BAM ! Vous avez cassé votre site web ! Enfin, du moins jusqu'à ce que vous corrigiez votre code.

C'est pourquoi garder les choses simples, en les intégrant au noyau de Joomla, signifie moins de frustration, moins de temps perdu à chercher vos erreurs sur Google, et plus de temps pour célébrer en vous installant confortablement dans votre fauteuil pour admirer votre nouveau site web.

Voyons donc ce que sont réellement les en-têtes HTTP, comment trouver le plugin et ce que vous pouvez en faire. Il convient de mentionner ici que cette fonctionnalité de Joomla est une fonction avancée de Joomla, plus adaptée aux sites web sensibles aux données qu'au nouveau site web que vous venez de créer avec amour sur vos mignons chatons. Cela dit, même les sites web simples devraient être aussi sécurisés que possible pour empêcher l'exécution de code malveillant après qu'ils aient piraté votre site web.

Que sont les en-têtes HTTP ?

Les en-têtes HTTP ne doivent pas être confondus avec la section <head> de votre document HTML. Ce sont des choses complètement différentes. Les en-têtes HTTP constituent le préambule entre votre serveur web et le navigateur. Un ensemble d'instructions qui indiquent au navigateur ce qu'il doit, ou plus important encore, ce qu'il ne doit pas afficher au visiteur.

Vous pouvez voir les en-têtes HTTP et la façon dont ils se rapportent aux objets HTML individuels dans les outils de développement de votre navigateur. Dans Google Chrome, ouvrez les outils de développement, puis l'onglet Réseau. Actualisez maintenant la page web et cliquez sur un élément HTML dans le panneau de gauche. L'en-tête HTTP de cet élément s'affichera dans le panneau de droite.

Vous pouvez voir dans l'image ci-dessous que l'image en surbrillance renvoie un statut HTTP 200, ce qui signifie que le navigateur l'a trouvée. Il existe également une série d'autres informations liées à cet élément, telles que la taille du fichier et les dates de modification.

Si l'un de vos éléments HTML n'a pas réussi à s'afficher, vous pouvez également trouver un indice sur la raison dans les en-têtes HTTP. Dans cet exemple, la deuxième image n'a pas réussi à s'afficher et vous pouvez voir, d'après les informations affichées dans le panneau de droite, qu'il n'y a aucune information d'en-tête HTTP.

Hormis le message cryptique :

Referrer Policy: 'strict-origin-when-cross-origin'

'Strict-origin-when-cross-origin' signifie simplement que lorsqu'un élément HTML (une image dans ce cas) est servi depuis une source différente (pas votre serveur), la politique d'en-tête HTTP définie à ce moment-là doit être respectée. Dans cet exemple, les en-têtes HTTP, tels que définis dans le plugin Joomla, rejetteront toutes les images qui ne proviennent pas de ce site web, ou d'un autre site web spécifiquement 'inclus' dans les paramètres d'en-tête HTTP définis dans le plugin En-têtes HTTP de Joomla.

Ainsi, lorsque l'image est appelée depuis le document HTML, le navigateur la rejette et elle n'est pas chargée.

Ce qui diffère du cas où elle n'est pas trouvée et renvoie un message d'erreur HTTP 404 non trouvé. Dans cette situation, l'image est toujours recherchée sur le serveur qui l'héberge, mais le navigateur ne l'a pas trouvée.

Ce que fait le Plugin En-têtes HTTP de Joomla

Outre le fait d'indiquer au navigateur ce qu'il doit afficher et de renvoyer des informations générales sur le document HTML, les en-têtes HTTP aident à atténuer les attaques et les vulnérabilités de sécurité que vous pourriez avoir sur votre site web Joomla. C'est là que le Plugin En-têtes HTTP de Joomla entre en jeu. Il y parvient en affichant explicitement le contenu HTML en fonction des paramètres que vous avez définis dans le Plugin En-têtes HTTP de Joomla lui-même.

En ajoutant des en-têtes HTTP de sécurité supplémentaires à votre site web Joomla avec le Plugin En-têtes HTTP, vous ajoutez une couche de sécurité supplémentaire à votre site web Joomla.

Ceci est important, car par défaut une page HTML affichera tout son contenu à votre visiteur, bon ou mauvais. À moins qu'il ne lui soit explicitement interdit de le faire dans les en-têtes HTTP de la page web. Le plugin permet de faire cela en autorisant la configuration des paramètres de sécurité avancés disponibles dans la Content-Security-Policy de votre site web. Le plugin peut être configuré différemment pour chaque site web selon vos besoins, c'est donc une arme véritablement flexible dans votre arsenal contre les pirates.

Pourquoi ai-je besoin de ce plugin ?

Dans un monde idéal, vous n'en auriez pas besoin. Cependant, dans le monde où nous vivons, il y a bien trop de gens sans scrupules qui cherchent des moyens de gagner de l'argent sur le dos des innocents et des imprudents. Dans notre monde, nous appelons ces gens des pirates (hackers). Les pirates font tout leur possible pour exploiter les vulnérabilités des logiciels à des fins lucratives, souvent au détriment du propriétaire du site web.

En utilisant le plugin En-têtes HTTP de Joomla pour contrôler le contenu servi à vos visiteurs, vous réduisez les chances que des pirates puissent servir du contenu malveillant à vos visiteurs via des plugins vulnérables obsolètes. Cela permet d'arrêter les injections de scripts malveillants sur votre site web.

Alors, réfléchissons un instant à cette situation hypothétique.

Vous avez un joli site Joomla 3. Il a été créé il y a 5 ans, et il fonctionne et a l'air encore parfait. Tous vos composants, plugins et modules sont à jour. Parfait, non ?

Eh bien, pas tout à fait, car lorsque vous avez créé votre site web il y a 5 ans, vous avez installé le plugin tendance Foo Bar pour afficher "FOO BAR" sur votre page d'accueil. Cela avait l'air cool au départ, mais après un moment vous avez changé d'avis et supprimé le raccourci {foo}FOO - BAR{/bar} des plugins dans votre article de page d'accueil.

Mais voici le problème : vous n'avez ni dépublié ni désinstallé le plugin lui-même, et son utilisation s'est effacée de votre mémoire. C'est quelque chose dont nous sommes TOUS coupables, j'en suis sûr.

Avance rapide jusqu'à aujourd'hui, 5 ans plus tard, ce plugin est toujours là, publié et actif sur votre site web, mais il n'a pas été mis à jour depuis 5 ans parce que vous avez depuis longtemps oublié son existence, ou que l'auteur a cessé de le maintenir. Maintenant, un individu malveillant s'est rendu compte que ce plugin présente une faille de sécurité pouvant être exploitée pour lancer une attaque de type Cross Site Scripting (XSS) sur votre site web, et faire de vos visiteurs sans méfiance des victimes.

Le Cross-site scripting, également connu sous le nom de XSS, est une vulnérabilité de sécurité de votre site web qui permet à un attaquant de compromettre les interactions que vos utilisateurs ont avec votre site web désormais vulnérable.

L'attaquant/pirate utilise le XSS pour exploiter votre site web vulnérable afin d'envoyer un script malveillant à votre utilisateur sans méfiance. Comme le script provient de votre site web, le navigateur de votre utilisateur ne sait pas ou ne soupçonne pas qu'il ne devrait pas être digne de confiance, et exécute le script au chargement et à l'ouverture de la page web.

Les scripts malveillants exécutés de cette manière peuvent causer de nombreux problèmes à votre utilisateur, du vol des mots de passe et identifiants conservés dans les cookies, jusqu'à l'envoi de votre utilisateur vers de faux sites web de phishing. Les scripts peuvent même modifier l'apparence de la page web que votre site web diffuse et afficher des publicités différentes.

L'utilisation du plugin En-têtes HTTP de Joomla permet d'arrêter le cross-site scripting en garantissant que seuls les scripts et le contenu que vous souhaitez servir à votre visiteur sont effectivement servis. Tout le reste est bloqué.

Ainsi, dans l'exemple ci-dessus, vous auriez pu configurer le plugin En-têtes HTTP pour ne servir les fichiers JavaScript (script) de votre site web qu'à partir d'un dossier spécifié, ou peut-être d'un CDN si vous en utilisez un, pour stopper l'attaque.

Vous pourriez aussi empêcher le site web d'exécuter du JavaScript en ligne intégré dans le HTML. Mais sachez que, selon la façon dont vous avez conçu le HTML de votre site web, cela pourrait causer des problèmes par la suite.

Cela permettrait alors d'empêcher l'exécution de code JavaScript malveillant sur votre site. Même si c'est votre plugin Foo Bar vulnérable qui serait à l'origine de la capacité d'un pirate à injecter du code malveillant sur votre site en premier lieu.

Remarque :

Les points faibles courants sur les sites web sujets aux attaques XSS sont les formulaires de saisie utilisateur (pages de connexion, formulaires d'inscription à la newsletter, formulaires de contact, etc.) sans validation ni chiffrement.

Où se trouve le Plugin En-têtes HTTP ?

Vous pouvez trouver le plugin En-têtes HTTP de Joomla avec tous les autres plugins Joomla et il s'utilise exactement de la même façon que vous en avez déjà l'habitude.

Utilisation du Plugin En-têtes HTTP

L'utilisation du plugin HTTP de Joomla est relativement simple, bien qu'il puisse être utile, avant de modifier les paramètres par défaut, de se familiariser avec certains termes spécifiques liés à son usage. Cela dit, certains d'entre eux devraient déjà vous être familiers.

Par exemple :

Lorsqu'il s'agit d'images, vous verrez le terme 'img-src', où 'img' fait référence aux images et 'src' à la source valide de l'image. Ce sont des termes que nous connaissons déjà grâce au HTML de base.

À la fin de cet article, vous trouverez une liste de sites web utiles contenant des informations complémentaires pour vous aider à utiliser ce plugin Joomla.

Paramètres du Plugin En-têtes HTTP - Onglet 1

Lorsque vous ouvrez le plugin, le premier onglet affiché contient les paramètres de base du plugin. Vous pouvez y ajuster les Options X-Frame, la Referrer-Policy, la Cross-Origin-Opener-Policy ainsi que Force HTTP Headers. Il y a également des liens vers des informations complémentaires pour vous aider à mieux comprendre ce que font ces éléments.

Examinons chacun d'entre eux à son tour.

X-Frame Options

Le premier paramètre concerne les X-Frame Options. Il est activé par défaut.

Cette option vous permet de décider si le contenu de votre site peut être affiché sur un autre site dans une <frame>, <iframe>, <embed> ou <object>. Si vous désactivez cette option, alors n'importe quel autre site peut afficher votre site dans une iframe.

Une fois activée, une balise 'x-frame-options: SAMEORIGIN' est ajoutée aux en-têtes de votre site. Cette balise vous permet toujours d'afficher votre propre contenu dans une <frame>, <iframe>, <embed> ou <object>, sur votre propre site. Mais personne d'autre ne peut afficher votre contenu dans une <iframe> sur son propre site.

L'en-tête X-Frame Options aide à protéger votre site et ses utilisateurs contre les attaques de 'Click Jacking'. Il s'agit d'un cas où un attaquant place une <iframe> sur son propre site et définit la source de l'<iframe> comme étant votre site. L'attaquant utilise ensuite plusieurs couches transparentes de son propre site par-dessus.

Cela trompe l'utilisateur qui clique sur un bouton ou un lien situé sur la couche transparente supérieure car il croit cliquer sur un lien dans l'iframe situé en dessous.

Ainsi, l'attaquant « détourne » des clics destinés à la page encadrée d'origine et les redirige vers une autre page web.

Plus grave encore, des pratiques similaires peuvent être utilisées pour récolter les frappes clavier correspondant aux identifiants et mots de passe de connexion à des comptes e-mail, des réseaux sociaux, et bien sûr, votre compte bancaire.

La plupart des navigateurs modernes prennent en charge les X-Frame Options, ce qui est une bonne chose. Ma recommandation est donc d'activer ce paramètre dans le plugin En-têtes HTTP afin de protéger vos utilisateurs contre le 'Click Jacking'.

La plupart des navigateurs modernes supportent les X-Frame Options.

Referrer-Policy

L'élément suivant dans la liste du premier onglet est le Referrer-Policy. Celui-ci, s'il est activé, permet de choisir quelle quantité de données potentielles de votre site web est transférée vers un autre site web lorsqu'un lien, ou un autre objet HTML, est cliqué sur votre site.

Communément, on voit ceci défini comme un attribut HTML sur les balises <a>, où l'on pourrait formater un lien comme <a href=”https://someplace.com” rel=”noreferrer”>Cliquez ici</a>. La balise noreferrer garde les détails de la page web expéditrice secrets vis-à-vis de la page web destinataire. Elle le fait en supprimant les informations de référence de l'en-tête HTTP de la page web.

Être conscient des données que votre site web pourrait « fuiter » vers un autre site web auquel vous créez un lien est une part importante de la sécurisation de votre site et de ses utilisateurs.

C'est particulièrement vrai si vous permettez l'inscription d'utilisateurs, si le site contient des données sensibles, ou si votre site web gère des transactions monétaires. Le plugin En-têtes HTTP de Joomla aide à contrôler cela à un niveau global, plutôt qu'au niveau de chaque lien individuel.

Par défaut, la Referrer Policy de votre site web est définie sur « strict-origin-when-cross-origin ». Cela ne bloque aucune des données de référence de la page web d'origine, sauf si elles sont envoyées vers une page http moins sécurisée. Mais, comme la plupart des pages web utilisent désormais https, c'est devenu un problème plus important qu'auparavant.

Il existe, bien sûr, de nombreuses utilisations innocentes de ces données « fuitées » si vous n'établissez pas de Referrer Policy pour votre site web. Celles-ci pourraient inclure des données collectées par le site web lié à des fins d'analyse, de journalisation, ou de mise en cache optimisée.

Malheureusement, tous les sites web référencés là-dehors n'utilisent pas vos données « fuitées » pour de telles opérations innocentes. Prenez la situation suivante comme exemple.

La plupart des sites web qui permettent l'inscription des utilisateurs auront un lien de réinitialisation de mot de passe à côté de leur formulaire de connexion sur une page de connexion/inscription. Il est également probable que la page web contienne d'autres liens vers des sites web externes, des liens vers les réseaux sociaux, ou peut-être quelques « Liens utiles » dans le pied de page.

Tous ceux-ci mènent hors de votre environnement sécurisé. Désormais, s'il n'y a pas de Referrer Policy en place, il est possible que l'en-tête de référent envoyé vers l'un de ces sites web externes lorsqu'un lien est cliqué depuis cette page de connexion, contienne le lien de réinitialisation du mot de passe. Ainsi que d'autres informations que vous avez partagées avec ce site web externe.

Cela pourrait poser un risque de sécurité pour l'utilisateur en compromettant ses données.

En raison du risque de sécurité potentiel sur ce type de page contenant des données sensibles, il est également recommandé de retirer tout contenu tiers de la page. Cela inclurait tous les liens et contenus fournis dans des <iframes> tels que les widgets de réseaux sociaux et les vidéos YouTube. Car les données saisies sur cette page pourraient être envoyées via l'en-tête de référent vers ces sites si vous cliquez sur cette mignonne vidéo de chaton qui vient d'apparaître.

Le plugin En-têtes HTTP de Joomla résout ce problème en permettant de choisir parmi 8 Referrer Policies pour établir une Referrer Policy pour votre site web. Chacune avec ses propres limites sur quand et combien de données partager.

Examinons cela de plus près. Il existe une excellente description sur la page des en-têtes de Mozilla qui les décrit ainsi :

• no-referrer
  L'en-tête de référent sera omis : les requêtes envoyées n'incluent aucune information de référent.
• no-referrer-when-downgrade
  Envoie l'origine, le chemin et la chaîne de requête dans l'en-tête de référent lorsque le niveau de sécurité du protocole reste identique ou s'améliore (HTTP→HTTP, HTTP→HTTPS, HTTPS→HTTPS). N'envoie pas l'en-tête de référent pour les requêtes vers des destinations moins sécurisées (HTTPS→HTTP, HTTPS→file).
• origin
  Envoie uniquement l'origine dans l'en-tête de référent. Par exemple, un document situé à l'adresse https://example.com/page.html enverra le référent https://example.com/.
• origin-when-cross-origin
  Lors d'une requête de même origine vers le même niveau de protocole (HTTP→HTTP, HTTPS→HTTPS), envoie l'origine, le chemin et la chaîne de requête. N'envoie que l'origine pour les requêtes d'origines différentes et les requêtes vers des destinations moins sécurisées (HTTPS→HTTP).
• same-origin
  Envoie l'origine, le chemin et la chaîne de requête pour les requêtes de même origine. N'envoie pas l'en-tête de référent pour les requêtes d'origines différentes.
• strict-origin
  Envoie uniquement l'origine lorsque le niveau de sécurité du protocole reste identique (HTTPS→HTTPS). N'envoie pas l'en-tête de référent vers des destinations moins sécurisées (HTTPS→HTTP).
• strict-origin-when-cross-origin (par défaut)
  Envoie l'origine, le chemin et la chaîne de requête lors d'une requête de même origine. Pour les requêtes d'origines différentes, envoie uniquement l'origine lorsque le niveau de sécurité du protocole reste identique (HTTPS→HTTPS). N'envoie pas l'en-tête de référent vers des destinations moins sécurisées (HTTPS→HTTP). Remarque : il s'agit de la politique par défaut si vous ne spécifiez aucune politique, ou si la valeur fournie n'est pas valide. Auparavant, la politique par défaut était no-referrer-when-downgrade.
• unsafe-url
  Envoie l'origine, le chemin et la chaîne de requête lors de toute requête, quelle que soit la sécurité. Alerte : cette politique risque de divulguer des informations potentiellement privées provenant d'URL de ressources HTTPS vers des origines non sécurisées. Évaluez soigneusement l'impact de ce paramètre.

Cross-Origin-Opener-Policy

La troisième option à définir dans le premier onglet est la Cross-Origin-Opener-Policy, une fonctionnalité de sécurité basée sur le navigateur qui permet de déconnecter différents « groupes de contexte de navigateur » les uns des autres.

L'utilisation des fenêtres pop-up en est un bon exemple. Le groupe de contexte de navigateur d'origine (tout le texte, les images, les liens, etc.) est déconnecté d'un nouveau groupe de contexte de navigateur qui est créé puis affiché dans la fenêtre pop-up.

Ce paramètre d'en-tête HTTP est assez approfondi et complexe, bien qu'il n'y ait que 3 options. Je vous encourage donc à consulter les liens ci-dessous pour mieux comprendre pourquoi ce paramètre devrait être activé sur votre site. Ainsi qu'à découvrir certaines des fonctionnalités avancées qui deviennent disponibles lorsque ce paramètre est actif.

Le Cross Origin Opener Policy permet de combler une faille historique dans la façon dont les navigateurs partagent des données entre différents groupes de contexte, en particulier lorsque des pop-ups sont utilisées sur le site.

Définir votre COOP vous aidera à atténuer les menaces liées à la sécurité des données, la plus courante étant appelée 'Spectre'. Spectre rend les données chargées dans le même groupe de contexte de navigateur que votre code potentiellement lisibles par un pirate. Spectre permet de mesurer le temps que prennent certaines opérations. Cela permet à ces pirates de deviner ce qui se trouve dans le cache du CPU. S'ils y parviennent, ils sauront ce qui se trouve dans la mémoire du processus. Ils ont alors accès à vos données. Qui pourraient être sensibles.

COOP fonctionne en isolant les données de votre document HTML d'origine des données HTML qui seraient affichées dans une pop-up issue du document d'origine. Cela permet d'éviter ce que l'on appelle les attaques cross-origin, ou XS-Leaks.

Ce processus ressemble au familier rel="noopener" que nous utilisons sur les liens classiques. Mais, contrairement au rel="noopener" qui n'est actif que sur les liens sortants, les documents pour lesquels le plugin Joomla a défini le cross-origin-opener-policy dans les en-têtes HTTP restreignent les données dans les deux directions. Ainsi, le document HTML avec une politique COOP active n'aura pas de référence à celui-ci dans l'en-tête HTTP, et la propriété window.opener de l'en-tête HTTP de la nouvelle fenêtre sera définie sur null.

Lors de la définition de ce paramètre dans le plugin En-têtes HTTP de Joomla, 3 options sont disponibles.

• unsafe-none
  C'est la valeur par défaut. Elle permet à votre document d'être ajouté au groupe de contexte de navigateur de son ouvreur, sauf si l'ouvreur lui-même a un cross-origin-opener-policy de same-origin ou same-origin-allow-pop-ups.
• same-origin-allow-popups
  Cette option conserve les références aux fenêtres ou onglets nouvellement ouverts qui ne définissent pas de cross-origin-opener-policy, ou qui refusent l'isolation en définissant eux-mêmes un cross-origin-opener-policy de unsafe-none.
• same-origin
  Isole le groupe de contexte de navigateur uniquement aux documents de même origine. Les documents cross-origin ne sont pas chargés dans le même groupe de contexte de navigateur.

Force HTTP Headers

La dernière option à examiner dans le premier onglet est Force HTTP Headers, à ne pas confondre avec 'Force HTTPS' dans les paramètres généraux de Joomla.

Cette section du plugin En-têtes HTTP de Joomla permet d'ajouter, si vous le souhaitez, une sélection d'« autres » en-têtes non détaillés spécifiquement dans les onglets du plugin, ainsi que de forcer l'inclusion de certains de ceux qui y figurent.

Dans la liste déroulante, vous disposez actuellement de 10 options. Mais il convient de noter que certaines d'entre elles pourraient être abandonnées avec le temps car les politiques d'en-tête auxquelles elles se réfèrent sont amenées à changer, ou à être repensées.

Les en-têtes HTTP actuels que vous pouvez définir directement ici ciblent les éléments suivants :

Vous pouvez obtenir plus d'informations sur chaque fonctionnalité sur le site des développeurs Mozilla.

Content-Security-Policy (liste)

L'en-tête de réponse Content-Security-Policy permet aux sites web de contrôler les ressources que l'utilisateur peut charger pour chaque page web. Les politiques spécifient principalement les origines des serveurs et les points de terminaison des scripts. Cela aide à se prémunir contre les attaques de type cross-site scripting. Mozilla : Content-Security-Policy

Content-Security-Policy-Report-Only

L'en-tête de réponse HTTP Content-Security-Policy-Report-Only permet aux développeurs web d'expérimenter des politiques en surveillant (mais sans les appliquer) leurs effets. Mozilla : Content-Security-Policy-Report-Only

Cross-Origin-Opener-Policy (COOP)

L'en-tête de réponse HTTP Cross-Origin-Opener-Policy (COOP) permet de garantir qu'un document de premier niveau ne partage pas un groupe de contexte de navigateur avec des documents cross-origin. Mozilla : Cross-Origin-Opener-Policy

COOP isolera le processus de votre document et les pirates potentiels ne pourront pas accéder à votre objet global s'ils tentaient de l'ouvrir dans une pop-up, empêchant ainsi un ensemble d'attaques cross-origin appelées XS-Leaks.

Expect-CT (À être abandonné)

L'en-tête Expect-CT permet aux sites d'opter pour le signalement et/ou l'application des exigences de transparence des certificats, afin d'éviter que l'utilisation de certificats mal émis pour ce site ne passe inaperçue. Mozilla : Expect-CT (À être abandonné)

Feature-Policy (Désormais obsolète)

L'en-tête HTTP Feature-Policy fournit un mécanisme permettant d'autoriser ou de refuser l'utilisation de fonctionnalités du navigateur dans son propre cadre, et dans le contenu de tout élément <iframe> du document. Mozilla : Feature-Policy

Permissions-Policy

Ceci remplace le Feature-Policy ci-dessus. Mozilla : Permissions-Policy (Remplace la Feature Policy ci-dessus)

Referrer-Policy (dans la liste)

L'en-tête HTTP Referrer-Policy contrôle la quantité d'informations de référent (envoyées avec l'en-tête de référent) qui doit être incluse dans les requêtes. Mozilla : Referrer-Policy

Report-To

Fait partie du Content-Security-Policy. Le champ d'en-tête de réponse HTTP Content-Security-Policy Report-To indique à l'agent utilisateur de stocker les points de terminaison de signalement pour une origine. Mozilla : Report-To

La directive report-to est destinée à remplacer la directive obsolète report-uri, report-to n'est pas encore supporté par la plupart des navigateurs.

Strict-Transport-Security

L'en-tête de réponse HTTP Strict-Transport-Security (souvent abrégé HSTS) informe les navigateurs que le site ne doit être accessible qu'en HTTPS, et que toute tentative future d'y accéder en HTTP doit être automatiquement convertie en HTTPS. Mozilla : Strict-Transport-Security

Ceci est plus sûr que de simplement configurer une redirection HTTP vers HTTPS (301) sur votre serveur, où la connexion HTTP initiale reste vulnérable à une attaque de type homme du milieu.

X-Frame-Options (dans la liste)

L'en-tête de réponse HTTP X-Frame-Options indique si un navigateur doit être autorisé à afficher une page dans un <frame>, <iframe>, <embed> ou <object>, ou non. Les sites peuvent l'utiliser pour éviter les attaques de type click-jacking, en veillant à ce que leur contenu ne soit pas intégré dans d'autres sites. Mozilla : X-Frame-Options

La sécurité supplémentaire n'est fournie que si l'utilisateur accédant au document utilise un navigateur qui prend en charge X-Frame-Options.

L'en-tête X-Frame-Options a des éléments enfants appelés frame-ancestors qui remplacent l'en-tête Frame-Options. Si une ressource possède les deux politiques, la politique frame-ancestors sera appliquée et la politique X-Frame-Options sera ignorée.

En utilisant le champ Valeur de l'en-tête HTTP, vous pouvez définir les valeurs que vous souhaitez appliquer et les assigner à votre site web, au site d'administration, ou aux deux.

Paramètres du Plugin En-têtes HTTP - ONGLET 2

Strict-Transport-Security (HSTS)

L'onglet Strict Transport Security Policy est désactivé par défaut.

J'adore faire des recherches. Parce que parfois on tombe sur un vrai moment OMG ! Et c'est l'un de ces moments.

Wikipédia indique :

Netscape Communications a créé HTTPS en 1994 pour son navigateur Netscape Navigator. À l'origine, HTTPS était utilisé avec le protocole SSL. Alors que SSL a évolué vers Transport Layer Security (TLS), HTTPS a été formellement spécifié par la RFC 2818 en mai 2000. Google a annoncé en février 2018 que son navigateur Chrome marquerait les sites HTTP comme « Non sécurisé », après juillet 2018. Cette démarche visait à encourager les propriétaires de sites web à mettre en œuvre HTTPS, dans un effort pour rendre le World Wide Web plus sûr. » ……

Qui aurait cru que Netscape avait inventé les protocoles HTTPS il y a si longtemps ? Ce qui est encore plus surprenant, c'est le temps qu'il a fallu pour l'intégrer à l'internet que nous connaissons et apprécions aujourd'hui.

Depuis des années maintenant, ils nous ont cajolés, intimidés, et finalement menacés, pour que nous mettions en œuvre HTTPS sur tous nos sites web. La plupart d'entre nous ont capitulé et le World Wide Web est désormais enfin sécurisé. Ou l'est-il vraiment ?

Il existe cependant quelques irréductibles, des inconditionnels ou des sites web oubliés qui n'utilisent encore que le http pour délivrer leur contenu, bien qu'avec un avertissement Google/Firefox etc. « Ce site n'est pas sécurisé ».

Une recherche rapide sur Google a fait apparaître plusieurs listes obsolètes de ces sites web « coupables de n'utiliser que HTTP ». Bien que depuis la publication de ces listes, de nombreux sites web soient passés à HTTPS. Cependant, il y avait des exclusions évidentes d'organisations dont on aurait pensé qu'elles devraient en savoir plus.

Par exemple :

• NGINX (http://nginx.org/)
• GNU (http://www.gnu.org/)
• L'Université de Washington (http://www.washington.edu/)

Selon w3techs.com, environ 20 % de tous les sites web fonctionnent encore uniquement en HTTP.

Alors, pourquoi est-ce un problème ?

C'est un problème car toute donnée envoyée depuis et reçue par le navigateur d'un utilisateur risque d'être interceptée. Nous appelons cela une attaque de type homme du milieu. Or, cela peut sembler sans importance si votre site web ne concerne que des photos de chatons mignons.

Mais même des sites web simples peuvent être victimes de pirates et d'attaquants qui mettront en œuvre le click-jacking et d'autres attaques cross-origin qui nuiront à vos utilisateurs.

Un site web qui n'échange aucune donnée utilisateur, ni information de connexion, devrait tout de même utiliser HTTPS.

Bon, revenons à notre sujet.

Comme vous le savez déjà, le but de HTTPS est d'introduire une connexion sécurisée entre le navigateur de l'utilisateur et votre serveur. Une connexion où tout échange de données se déroule dans un environnement sécurisé qui ne peut pas être intercepté et copié par un tiers. Un homme du milieu.

Mais, saviez-vous que sauf si votre certificat SSL HTTPS utilise TLS, votre connexion « sécurisée » n'est pas aussi sécurisée que vous pourriez le croire ? Les connexions HTTPS non TLS restent vulnérables aux attaques de type homme du milieu.

Bien qu'ancien, cet article de blog explique bien comment fonctionne une attaque de type homme du milieu.

Les navigateurs ont largement adopté TLS.

Et, TLS 1.3 n'est pas directement compatible avec les versions précédentes, à moins d'être exécuté en mode de compatibilité. Ce qui pourrait poser un problème pour certains.

Utiliser le Plugin En-têtes HTTP de Joomla pour gérer Strict-Transport-Security (HSTS) aide à atténuer les attaques de type homme du milieu en imposant l'utilisation de TLS dans le navigateur web de vos visiteurs. TLS garantit que toute communication web se déroule côté client via une couche de transport sécurisée.

Utilisez-vous une redirection 301 pour servir la version HTTP non sécurisée de votre site web vers la version HTTPS sécurisée ?

La plupart des gens le font. Les redirections 301 sont des instructions que la plupart des propriétaires de sites web configurent dans leur fichier htaccess. Elles informent Google que la version du site web à utiliser est la version HTTPS (sécurisée). Le problème est que la redirection 301 n'est qu'une redirection d'URL, donc votre site web effectue tout de même une partie de la connexion initiale en HTTP.

Contrairement aux connexions entre un utilisateur et un serveur de site web qui utilisent HSTS, où le serveur interagit automatiquement uniquement via HTTPS.

HSTS présente néanmoins une faiblesse, car la toute première connexion initiale entre le navigateur de l'utilisateur et le serveur du site web se fait encore en HTTP. Mais toutes les connexions suivantes sont automatiquement établies via HTTPS jusqu'à ce que la date d'expiration de l'en-tête HTTP soit atteinte et que cet en-tête soit réinitialisé.

Ceci est différent d'une redirection 301 standard où chaque chargement de page inclut une requête http initiale pour initier la connexion https.

Il existe une solution à cette faiblesse dans les paramètres HSTS des En-têtes HTTP : activer « Preload ».

Ce qui ajoutera la balise « Preload » à l'en-tête de réponse.

Dans les paramètres, il y a également une liste de préchargement de liens**. C'est une liste codée en dur dans de nombreux navigateurs modernes. La liste informe le navigateur que la connexion à example.com ne doit être établie que via HTTPS. Supprimant ainsi la nécessité de faire même la connexion initiale via HTTP.

Une fois HSTS configuré dans le plugin En-têtes HTTP de Joomla, toutes les balises nécessaires sont ajoutées à l'en-tête de réponse HTTP. Cela indique à tout navigateur d'utilisateur essayant de se connecter à votre serveur que toutes les connexions doivent être établies avec HTTPS, que cela soit spécifié dans votre HTML ou non.

En résumé, utiliser le plugin En-têtes HTTP de Joomla pour intégrer HSTS plutôt que de dépendre des redirections 301 pour servir votre contenu via HTTPS est une amélioration de sécurité importante. Une amélioration qui aide à stopper les attaques de type homme du milieu, et fournit à votre utilisateur un environnement sécurisé.

HSTS couvre l'intégralité du domaine, contrairement à une redirection 301 qui ne couvre qu'un chemin URI spécifique.

HSTS utilise un cache de navigateur séparé qui est généralement isolé, de sorte qu'il ne peut pas être effacé facilement ou accidentellement.

HSTS peut être préchargé dans un navigateur. Cela garantit qu'un utilisateur se connecte uniquement à votre serveur via HTTPS, qu'il ait déjà visité le site auparavant ou non.

Paramètres du Plugin En-têtes HTTP - ONGLET 3

Content Security Policy (Onglet 3)

L'onglet Content Security Policy est désactivé par défaut.

Lorsque vous activez la Content Security Policy de Joomla via le plugin En-têtes HTTP, vous indiquez exactement au navigateur de votre visiteur quelles ressources charger depuis le serveur de votre site web. C'est un excellent moyen de garantir que vous ne délivrez que le contenu que vous souhaitez réellement délivrer.

Mettre en place une Content Security Policy efficace est un moyen efficace d'empêcher les attaques de type Cross-Site Scripting (XSS) et Click Jacking provenant de votre site web.

Le Cross-Site Scripting, aussi appelé attaque XSS, est une attaque contre votre site web où un script malveillant est « injecté » dans un site web de confiance sans qu'il s'en doute. Les pirates trouvent un point faible à exploiter, généralement un endroit où un utilisateur peut saisir des données.

Des composants obsolètes permettant la saisie utilisateur, des formulaires de commentaires non validés, par exemple, peuvent présenter des vulnérabilités exploitables dans le cadre d'une attaque Cross Site Scripting. C'est pourquoi il est toujours recommandé de mettre à jour vos composants Joomla et de limiter ces opportunités.

Donc, en prenant comme exemple le formulaire de commentaires infecté :

Votre site web utilise un formulaire de commentaires à la fin d'un article pour recueillir les discussions des utilisateurs, comme le font de nombreux sites web. Ce qui est très bien.

Votre extension de commentaires provenant de dodgy-joomla-extensions.com fonctionne très bien et vos utilisateurs l'adorent. Mais vous ne l'avez pas mise à jour depuis 5 ans et les développeurs l'ont abandonnée depuis longtemps.

Maintenant, 5 ans plus tard, Monsieur Pirate se rend compte qu'en raison d'une vulnérabilité dans le code du composant de commentaires, il peut cacher un bout de code malveillant dans un commentaire qui semble par ailleurs innocent.

Ce que ce code finit par faire varie, mais vous pouvez être sûr qu'à chaque fois que votre page d'article innocente se charge, avec les commentaires, ce mauvais code est également chargé et exécuté. Il fait partie du HTML après tout, et le navigateur ne sait pas qu'il n'est pas censé être là, ni fiable.

Ainsi, le mauvais code s'exécute. Peut-être qu'il vérifie les données de vos cookies. Peut-être qu'il vole des données sensibles conservées par le navigateur. Ou peut-être qu'il charge des publicités de casinos en ligne, ou de sites web pour adultes. Peut-être qu'il recharge complètement le HTML de votre page web innocente sur ces chatons mignons depuis un fichier JavaScript externe pour voler les détails de carte bancaire de vos utilisateurs.

En fait, à ce stade, un script peut être exécuté pour accomplir presque n'importe quoi.

Une bonne Content Security Policy aide à arrêter ce type d'attaque, même si votre extension de commentaires compromise devient la cible de Monsieur Pirate.

Elle y parvient car le plugin En-têtes HTTP de Joomla délivre la CSP en tant qu'en-tête de réponse HTTP, qui indique explicitement au navigateur ce qu'il doit charger. Dans les paramètres de l'onglet CSP du plugin En-têtes HTTP, vous pouvez cibler directement 28 directives de politique. Les directives aident à sécuriser votre site web en n'utilisant que des sources approuvées pour vos fichiers et votre contenu.

L'exemple d'attaque ci-dessus avait fini par charger un fichier JavaScript depuis une autre source pour modifier le rendu HTML affiché à l'écran. Cela aurait pu être évité en ajoutant la directive script-src 'self' au CSP de Joomla! dans le plugin.

Dans cet exemple, le navigateur ne chargera les fichiers JavaScript du document HTML que s'ils proviennent de votre domaine. Tous les autres fichiers JavaScript seront rejetés, y compris ceux de M. Pirate.

Bien que cela contribue à sécuriser votre site, cela peut aussi empêcher le chargement d'autres fichiers JavaScript légitimes que vous souhaitez charger lors du rendu de la page web à l'écran. Ces fichiers externes peuvent être ajoutés comme sources autorisées (liste blanche) dans la même directive. Par exemple, si vous utilisez bootstrap depuis un CDN, vous ajouteriez :

script-src 'self' https://cdn.jsdelivr.net

Dans cet exemple, si vous avez des difficultés à charger bootstrap depuis le CDN, https://cdn.jsdelivr.net, vous pourriez essayer d'ajouter l'URL complète du fichier bootstrap dont vous avez besoin. Vous formateriez alors votre directive ainsi : script-src 'self' https://cdn.jsdelivr.net/npm/[email protected]/dist/js/bootstrap.min.js.

L'ajout de ces sources externes serait plus facile à mettre en œuvre sur un nouveau site web lors de sa construction. Mais si vous parcourez votre HTML généré avec les outils de développement, vous devriez pouvoir trouver tous les fichiers externes déjà utilisés sur votre site existant, et les inclure dans votre CSP.

Lors de l'ajout de directives à votre Content Security Policy dans le plugin En-têtes HTTP, il existe une série de valeurs essentielles que vous pouvez utiliser pour définir ce qui doit être explicitement chargé par le navigateur. Voici les valeurs de base pour configurer votre première Content Security Policy.

D'autres paramètres sont disponibles pour certaines directives plus avancées ; une liste plus complète et des exemples d'utilisation sont disponibles sur le site Content Security Policy (CSP) Quick Reference Guide.

• 'none' bloque l'utilisation de ce type de ressource.
• 'self' correspond à l'origine actuelle (mais pas aux sous-domaines).
• 'unsafe-inline' autorise l'utilisation de JS et CSS en ligne.
• 'unsafe-eval' autorise l'utilisation de mécanismes comme eval().

Alors, examinons certaines de ces directives. Voici une liste de quelques directives disponibles dans le plugin En-têtes HTTP de Joomla!, accompagnées d'une brève description, grâce à Content Security Policy. Je vous recommande de visiter ce site pour plus d'informations et d'exemples.

default-src

La directive default-src définit la politique par défaut pour le chargement de ressources telles que JavaScript, Images, CSS, Polices, requêtes AJAX, Frames, Médias HTML5.
EXEMPLE DE POLITIQUE DEFAULT-SRC
default-src 'self' https://cdn.example.com

script-src

Définit les sources valides de JavaScript.
EXEMPLE DE POLITIQUE SCRIPT-SRC
script-src 'self' https://js.example.com

style-src

Définit les sources valides de feuilles de style ou CSS.
EXEMPLE DE POLITIQUE STYLE-SRC
style-src 'self' css.example.com

img-src

Définit les sources valides d'images.
EXEMPLE DE POLITIQUE IMG-SRC
img-src 'self' https://img.example.com https://example.com

connect-src

S'applique à XMLHttpRequest (AJAX), WebSocket, fetch(), <a ping> ou EventSource. Si ce n'est pas autorisé, le navigateur émule un code de statut HTTP 400.
EXEMPLE DE POLITIQUE CONNECT-SRC
connect-src 'self'

font-src

Définit les sources valides de ressources de polices (chargées via @font-face).
EXEMPLE DE POLITIQUE FONT-SRC
font-src https://font.example.com https://example.com

object-src

Définit les sources valides de plugins, par ex. <object>, <embed> ou <applet>.
EXEMPLE DE POLITIQUE OBJECT-SRC
object-src 'self'

media-src

Définit les sources valides d'audio et de vidéo, par ex. les éléments HTML5 <audio>, <video>.
EXEMPLE DE POLITIQUE MEDIA-SRC
media-src https://media.example.com

frame-src

Définit les sources valides pour le chargement des frames. Dans CSP Level 2, frame-src a été dépréciée au profit de la directive child-src. CSP Level 3 a annulé la dépréciation de frame-src et continuera de recourir à child-src si elle n'est pas présente.
EXEMPLE DE POLITIQUE FRAME-SRC
frame-src 'self'

sandbox

Active un bac à sable (sandbox) pour la ressource demandée, similaire à l'attribut sandbox d'une iframe. Le bac à sable applique une politique de même origine, empêche les pop-ups, les plugins et le blocage de l'exécution de scripts. Vous pouvez laisser la valeur de sandbox vide pour conserver toutes les restrictions, ou ajouter des valeurs : allow-forms allow-same-origin allow-scripts allow-pop-ups, allow-modals, allow-orientation-lock, allow-pointer-lock, allow-presentation, allow-popups-to-escape-sandbox, et allow-top-navigation.
EXEMPLE DE POLITIQUE SANDBOX
sandbox allow-forms allow-scripts

report-uri

Demande au navigateur d'envoyer en POST les rapports d'échec de politique à cette URI. Vous pouvez également utiliser Content-Security-Policy-Report-Only comme nom d'en-tête HTTP pour demander au navigateur de simplement envoyer des rapports (sans rien bloquer). Cette directive est dépréciée dans CSP Level 3 au profit de la directive report-to.
EXEMPLE REPORT-URI
report-uri /some-report-uri

child-src

Définit les sources valides pour les web workers et les contextes de navigation imbriqués chargés à l'aide d'éléments tels que <frame> et <iframe>
EXEMPLE DE POLITIQUE CHILD-SRC
child-src 'self'

form-action

Définit les sources valides pouvant être utilisées comme action d'un <form> HTML.
EXEMPLE DE POLITIQUE FORM-ACTION
form-action 'self'

frame-ancestors

Définit les sources valides pour l'intégration de la ressource à l'aide de <frame> <iframe> <object> <embed> <applet>. Définir cette directive sur 'none' devrait être à peu près équivalent à X-Frame-Options: DENY. Lorsque cette directive est active, et si le navigateur la prend en charge, elle remplacera les paramètres de X-frame-options.
EXEMPLE DE POLITIQUE FRAME-ANCESTORS
frame-ancestors 'none'

plugin-types

Définit les types MIME valides pour les plugins invoqués via <object> et <embed>. Pour charger un <applet>, vous devez spécifier application/x-java-applet.
EXEMPLE DE POLITIQUE PLUGIN-TYPES
plugin-types application/pdf

base-uri

Définit un ensemble d'URL autorisées pouvant être utilisées dans l'attribut src d'une balise HTML base.
EXEMPLE DE POLITIQUE BASE-URI
base-uri 'self'

report-to

Définit un nom de groupe de rapport défini par un en-tête de réponse HTTP Report-To. Voir l'API de rapport pour plus d'informations.
EXEMPLE DE DIRECTIVE REPORT-TO
report-to groupName

worker-src

Restreint les URLs pouvant être chargées en tant que Worker, Shared Worker ou Service Worker.
EXEMPLE DE POLITIQUE WORKER-SRC
worker-src 'none'

manifest-src

Restreint les URLs à partir desquelles les manifestes d'application peuvent être chargés.
EXEMPLE DE POLITIQUE MANIFEST-SRC
manifest-src 'none'

prefetch-src

Définit les sources valides pour le prefetch de requêtes et le prérendu, par exemple via la balise link avec rel="prefetch" ou rel="prerender" :
EXEMPLE DE POLITIQUE PREFETCH-SRC
prefetch-src 'none'

navigate-to

Restreint les URLs vers lesquelles le document peut naviguer, par quelque moyen que ce soit. Par exemple, lorsqu'un lien est cliqué, qu'un formulaire est soumis, ou que window.location est appelé. Si form-action est présent, cette directive est ignorée pour les soumissions de formulaire. Statut d'implémentation
EXEMPLE DE POLITIQUE NAVIGATE-TO
navigate-to https://example.com

Le plugin En-têtes HTTP de Joomla vous permet également de définir certains paramètres globaux dans l'onglet Content Security Policy.

Vous pouvez choisir d'appliquer la CSP à votre site web, au site d'administration, ou aux deux avec le paramètre client.

L'option 'Report-Only' vous permet de tester vos directives et de vérifier les erreurs avec les outils de développement avant la mise en ligne. C'est toujours amusant de traquer la raison des erreurs CSP dans la console de Google !

Vient ensuite le paramètre 'Nonce'. Nonce, signifiant 'nombre utilisé une seule fois', est un système qui applique une chaîne générée aléatoirement à une balise <script> ou <style> en ligne incluse dans votre HTML via l'API Joomla. Ces instances sont généralement mises en œuvre par des développeurs tiers de composants / modules / plugins Joomla lorsque vous installez cette fonctionnalité supplémentaire sur votre site web.

Dans l'image ci-dessous, vous pouvez voir la balise <style> avec un attribut nonce qui a été ajouté au <styles> CSS ajouté à mon document HTML par le composant Akeeba Backup.

Fait intéressant, le code JavaScript et CSS du cœur de Joomla qui est ajouté au document HTML n'inclut actuellement pas de balise 'nonce'. Ceci est dû au fait qu'il fait partie du 'cœur' plutôt que d'être ajouté via l'API Joomla.

Si vous activez le bouton bascule 'Nonce' dans les paramètres CSP, vous permettez à ces scripts et styles en ligne d'être interprétés par le navigateur comme 'sûrs'. Vous devrez également définir la balise Joomla {nonce} dans votre directive de politique script-src en script-src 'self' {nonce}. Comme solution de repli pour les anciens navigateurs qui ne supportent pas les 'nonces', vous pouvez également ajouter {script-hashes} après le paramètre fictif {nonce}, comme ceci script-src 'self' {nonce} {script-hashes} (faites attention à l'espacement). Mais n'oubliez pas d'activer d'abord Script Hashes.

Joomla génère aléatoirement la chaîne de texte 'nonce' et l'ajoute aux balises <style> et <script>. Lorsque vous activez l'option 'nonce' dans les paramètres du plugin, la chaîne de texte est transmise à l'en-tête HTTP. Le navigateur interprète alors l'en-tête HTTP et traite la <script> ou <style> correspondante. En même temps, il supprime la chaîne de texte Nonce du HTML rendu dans le navigateur.

Cela empêche Mr Hacker de détourner la chaîne de texte nonce et de l'ajouter à son propre code injecté. Même si Mr Hacker réussit à injecter son JavaScript malveillant dans votre HTML, le navigateur le bloquera.

Script Hashes

Nous savons tous que nous ne devrions pas inclure de JavaScript en ligne dans notre HTML, il faudrait l'écrire dans un fichier my-javascript.js et l'ajouter au <head> ou le placer juste avant la balise </body>. Mais nous sommes tous coupables de le faire de temps en temps.

Le problème est que si vous faites cela, puis ajoutez la directive CSP 'script-src 'self'', tout le JavaScript en ligne sera bloqué par défaut. C'est conçu pour fonctionner ainsi afin d'empêcher le JavaScript injecté par Mr Hacker de s'exécuter sur votre site.

Il existe une dérogation à cela avec la directive script-src 'unsafe-inline', qui permettra au JavaScript en ligne de Mr Hacker de s'exécuter, ainsi que votre code de confiance. Ce n'est pas la meilleure option, pour des raisons évidentes.

Script Hashes à la rescousse !

Le plugin En-têtes HTTP de Joomla collecte automatiquement tous les <styles> et <scripts> transmis via l'API Joomla vers le site. Il génère ensuite les hashes respectifs et les transmet via l'en-tête HTTP. Le navigateur génère alors les hashes sur le site lui-même et confirme que les hashes correspondent. Si c'est le cas, les scripts sont exécutés, sinon ils sont bloqués.

Pour activer cette fonctionnalité du plugin, basculer le commutateur sur 'Activé'. Ensuite, dans votre directive de politique script-src, ajouter la valeur 'self' {script-hashes}. Si vous utilisez la fonctionnalité 'nonce' en plus des 'script hashes', définissez la valeur de la directive comme dans l'exemple de nonce ci-dessus.

Voilà qui est astucieux.

Mais ce qui est encore mieux, c'est que nous pouvons utiliser la même idée pour traiter les script hashes manuellement et les ajouter à notre directive script-src 'self'. Cela demandera un peu de travail à mettre en place et à maintenir, mais pourrait vous sauver la mise si vous avez ajouté du JavaScript à un article ou à un module personnalisé.

Il existe des méthodes plus détaillées pour cela utilisant un générateur de hash sha256, sha384 ou sha512. Mais comme la plupart des gens n'ajouteront que de petits extraits de JavaScript à leur article ou module personnalisé, nous laisserons les outils de développement de Google faire le travail pour nous.

Le processus est simple. La seule différence est la façon dont nous générons le hash.

En supposant que vous ayez activé le plugin En-têtes HTTP de Joomla, que la CSP soit active et que vous ayez défini et enregistré la directive script-src 'self'.

Étape 1 - Ajouter votre JavaScript en ligne à votre article ou module personnalisé et l'enregistrer. Ne pas oublier d'ajuster les paramètres de votre éditeur pour empêcher celui-ci de supprimer votre code lors de l'enregistrement.

Étape 2 - Naviguer vers votre page web contenant votre script. Ouvrir les outils de développement et, dans l'onglet console, vous verrez une erreur ressemblant à :

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='), or a nonce ('nonce-...') is required to enable inline execution.

Étape 3 - Il ne vous reste plus qu'à copier/coller le hash du message d'erreur dans votre directive JavaScript du plugin et à l'enregistrer à nouveau :

script-src 'self' 'sha256-0Q1c1CuhLHV7WbNt+ltwJoCf3wF/O+MWqsXetkxWSm0='

Ensuite, rechargez votre page web et vérifiez à nouveau dans les outils de développement de Google. L'erreur aura disparu et le navigateur chargera votre script sur la page web.

Remarque : Une erreur apparaît encore dans mon exemple car le JavaScript ajouté à mon article n'est pas complet. Mais cela montre qu'au moins le code en ligne tente de fonctionner.

Ajouter des hashs à votre code en ligne est une bonne façon de les mettre sur liste blanche dans l'en-tête HTTP afin qu'ils soient tout de même exécutés, tandis que tout code en ligne qui n'est pas explicitement haché et ajouté à votre CSP restera bloqué. Cela contrecarre ainsi la tentative de Monsieur Pirate de compromettre votre site Web.

Remarque :

Si vous modifiez votre JavaScript, vous devrez recalculer votre hash et modifier la valeur dans la directive CSP.

Si vous rencontrez des problèmes pour faire fonctionner vos hashs, il existe 3 problèmes courants ; vous trouverez des solutions sur la page web Using a hash with CSP.

Strict Dynamic

Si vous activez le paramètre Strict Dynamic dans votre CSP, cela prendra l'autorité explicite que vous avez accordée à un script via un Hash, ou un Nonce, et l'appliquera à tout autre script directement lié à celui-ci, ou appelé depuis celui-ci. Cette action remplace également les directives par défaut telles que 'self' ou 'unsafe-inline' appliquées dans vos directives CSP générales à ces scripts enfants. Elles seront ignorées.

Style Hashes

Le Style Hash du CSP fonctionne exactement de la même manière que les hashs JavaScript décrits ci-dessus, mais à utiliser si vous ajoutez des blocs CSS <style> dans le corps de votre HTML. Tout comme pour l'utilisation de 'Script Hashes', Activer la fonctionnalité du plugin et définir une directive de politique style-src pour y faire référence avec la valeur 'self' {style-hashes}.

Remarque :

Si vous modifiez votre CSS en ligne, plutôt que le CSS créé par l'API Joomla, vous devrez recalculer votre hash et modifier la valeur dans la directive CSP.

Frame Ancestors 'self'

Ce paramètre du plugin permet qu'une page soit encadrée, par exemple, dans une iframe, mais uniquement depuis le même site.

Si vous souhaitez autoriser explicitement un autre site Web à encadrer votre contenu, vous pouvez mettre en place une directive spécifique 'frame-src'.

Note finale / Conclusion :

En rédigeant cet article, j'ai réalisé que je n'ai fait qu'effleurer ce vaste sujet.

J'adore découvrir des sujets que j'avais auparavant ignorés, ou que je ne connaissais pas. Est-ce votre cas également ?

La conclusion à laquelle je suis arrivé en étudiant le sujet des en-têtes HTTP, et en particulier l'utilisation du nouveau plugin J4 de Joomla pour les configurer, est que nous devons tous maîtriser ce sujet. Il y a bien trop de personnes (des pirates) qui attendent simplement une occasion de profiter de sites Web à la sécurité faible. Alors, n'aidez pas vos utilisateurs à devenir des victimes.

Amusez-vous à explorer le plugin En-têtes HTTP de Joomla et découvrez comment il peut aider à sécuriser votre site Web.

Je vous recommande toutefois d'approfondir vos recherches sur ce sujet intéressant avant de commencer. Vous trouverez ci-dessous des liens pour démarrer vos propres recherches. Vous comprendrez beaucoup mieux comment fonctionne internet et comment votre site web interagit avec lui.

Pour Référence

Si vous devez réinitialiser le plugin, le plugin En-têtes HTTP a été installé avec les paramètres suivants :

Le plugin est Activé par défaut.

• Les onglets HSTS et CSP sont Désactivés par défaut.
• Les X-Frame-Options sont Activées par défaut.
• Le Referrer-Policy est initialement défini sur : strict-origin-when-cross-origin.
• Le Cross-Origin-Opener-Policy est initialement défini sur same-origin.

Si vous avez lu jusqu'ici en pensant « Ce n'est pas juste, qu'en est-il de J3 ? », « Pourquoi ne pourrions-nous pas avoir les mêmes fonctionnalités dans Joomla 3 ? ». Eh bien, la bonne nouvelle, c'est que c'est possible. Bien que vous deviez télécharger le plugin depuis le JED.

Une fois que vous avez configuré vos en-têtes HTTP avec le plugin Joomla 4, vous pouvez tester vos en-têtes HTTP sur le site web Security Headers.

Quel score avez-vous obtenu ?

Sachez que l'activation du plugin En-têtes HTTP peut avoir des effets inattendus sur le frontal.

Enfin, je tiens à remercier Tobias Zulauf & Ced Keiflin pour leur contribution à la finalisation de cet article dans les délais !