En bref : une mise à jour silencieuse d'extension supprime les en-têtes CSP en vertu de la clause W3C de priorité utilisateur
- CSP n'est pas absolu : La plupart des équipes traitent la CSP comme une frontière infranchissable. La spécification CSP3 dit pourtant le contraire : la politique ne doit pas interférer avec les add-ons, car c'est l'agent utilisateur qui a la priorité. Une extension peut supprimer vos 31 directives sans que votre grand-père ne voie jamais apparaître la moindre invite de consentement.
- cside voit la suppression : cside détecte le comportement à l'exécution du navigateur, une fois que la requête a déjà échappé à votre contrôle. Quand une extension mise à jour en silence retire l'en-tête que vous aviez déployé pour protéger une page de paiement, c'est ce comportement qui déclenche l'alerte, puisque le report-uri sur lequel vous comptiez ne se déclenche jamais une fois l'en-tête disparu.
- Ajoutez l'observation runtime : Il est peu probable que le W3C réécrive la clause de priorité selon votre calendrier. La vraie question est donc de savoir si la CSP reste votre seule défense côté client, ou si vous ajoutez une observation des scripts à l'exécution qui continue de fonctionner pour l'extension qu'un utilisateur a installée il y a six ans et oubliée depuis.
Peu de temps ? Découvrez le blocage Magecart et skimmer dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
Lorsque les Content Security Policies (CSP) ont été introduites, leur périmètre initial visait à atténuer les attaques de type Cross-Site Scripting (XSS) et les injections malveillantes côté client via des ressources chargées côté client. Au fil du temps, la CSP a évolué et compte aujourd'hui 31 directives au total, avec des niveaux de support variables selon les navigateurs et 3 formats de reporting distincts.
Ces en-têtes permettent au propriétaire d'un site web de définir quelles sources sont autorisées à charger du JavaScript. Des polices, des feuilles de style ou des iFrames. Ils permettent également de définir les connexions externes susceptibles d'exfiltrer des données. Une CSP correctement implémentée peut prévenir des comportements indésirables. Mais la CSP n'est pas très conviviale et présente quelques défauts majeurs, que vous pouvez découvrir ici.
Cela dit, une extension de navigateur devrait-elle pouvoir supprimer silencieusement ces en-têtes ?
La logique de la spécification
« La politique appliquée à une ressource ne devrait pas interférer avec le fonctionnement des fonctionnalités de l'agent utilisateur telles que les modules complémentaires, les extensions ou les bookmarklets. Ces types de fonctionnalités font généralement primer la priorité de l'utilisateur sur celle des auteurs de pages, comme le préconise [HTML-DESIGN]. »
Pour le dire simplement, votre navigateur est votre client. Votre client a la priorité sur la sécurité de la page web que vous visitez. C'est logique. Si ce n'était pas le cas, il est probable que les navigateurs le feraient quand même. Dans le monde actuel, les navigateurs peuvent décider de ne pas faire ce qui est spécifié, de toute façon. Une spécification du W3C est souvent perçue comme un objectif final atteint au prix de compromis en chemin.
Cependant…
Tout le monde voit bien le problème, non ?
Ma préoccupation :
« Certes, W3C, mais mon grand-père ne saurait pas qu'en installant une extension, il lui permet de supprimer des fonctionnalités de sécurité essentielles des sites web. »
Le problème va encore plus loin. De nombreux navigateurs mettent à jour les extensions de manière automatique, sans approbation explicite ni opt-in. Cela signifie qu'une extension peut se comporter de façon radicalement différente du jour au lendemain, sans que vous en soyez informé.
Malheureusement, tout au long de ma carrière, j'ai constaté que les gens ne pensent généralement pas à leurs parents ou grands-parents lorsqu'ils conçoivent de la technologie. Négligence inconsciente ou autre chose - un jour, nous serons vieux et nos enfants pourraient nous faire la même chose. Pourquoi sommes-nous ainsi ?
Les navigateurs sont des machines à fonctionnalités. La sécurité est une fonctionnalité. Si des problèmes de sécurité sérieux surviennent, une réponse finira par émerger sous la pression extérieure et les protestations. Mais la priorité reste les fonctionnalités tape-à-l'œil, et la sécurité n'est tout simplement pas traitée comme la priorité numéro 1.
Quelle solution envisager ?
Cela dépasse le cadre du W3C. Cela devrait s'inscrire dans le cadre plus large de la sécurité des navigateurs, un cadre qui pousse les éditeurs de navigateurs à s'autoréguler et à prendre la sécurité au sérieux.
Je me pose la question : pourquoi ne pas en faire un opt-in explicite ?
Si une extension, lors de son installation ou d'une mise à jour, ajoute la fonctionnalité de supprimer ou de modifier des en-têtes de sécurité, l'utilisateur devrait en être informé et devoir approuver ce comportement.
La sécurité côté client est un espace problématique fascinant, le sujet abordé ci-dessus n'est qu'un exemple parmi de nombreuses choses fondamentalement mal implémentées et dangereuses. Bien que je soulève cette question au niveau du W3C, il s'agit en réalité d'un problème de sécurité inhérent à la conception des navigateurs.
Il y a encore beaucoup à dire. Protégez vos clients, essayez cside.
