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]. »
En termes simples, 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, les navigateurs le feraient probablement de toute façon. Dans le monde actuel, les navigateurs peuvent choisir de ne pas respecter les spécifications. 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 une priorité numéro 1.
Quelle solution envisager ?
Cela dépasse le cadre du W3C, mais devrait s'inscrire dans un cadre de sécurité des navigateurs plus large, encourageant une attitude d'autorégulation et de sensibilisation à la sécurité de la part des éditeurs de navigateurs.
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 utilisateurs, essayez cside.
