Problème de CSP #642

New issue

Closed

opened 2023-10-03 13:28:44 +00:00 by arnaudlevy · 2 comments

arnaudlevy commented

2023-10-03 13:28:44 +00:00

Sur https://example.osuny.org/fr/, nous avons un moteur de recherche qui tourne avec https://pagefind.app/.

Malheureusement, il ne tourne pas sur Garage, à cause de la Content-Security-Policy, si notre analyse est bonne.

Quand on clique sur la recherche, on charge le fichier pagefind/pagefind.js, qui va ensuite charger des fichiers wasm. Malheureusement, ce fichier est servi avec la Content-Secure-Policy "default-src https: 'unsafe-inline'; object-src 'none'".

Cela empêche le chargement des wasm, qui auraient besoin d'une policy 'unsafe-eval', ou bien de n'avoir pas de CSP.

Sur le site https://publications.arnaudlevy.com/, hébergé sur Netlify, tout fonctionne. Voilà les headers du fichier pagefind.js.

Sur https://example.osuny.org/fr/, nous avons un moteur de recherche qui tourne avec https://pagefind.app/. Malheureusement, il ne tourne pas sur Garage, à cause de la Content-Security-Policy, si notre analyse est bonne. Quand on clique sur la recherche, on charge le fichier `pagefind/pagefind.js`, qui va ensuite charger des fichiers wasm. Malheureusement, ce fichier est servi avec la Content-Secure-Policy "default-src https: 'unsafe-inline'; object-src 'none'". Cela empêche le chargement des wasm, qui auraient besoin d'une policy 'unsafe-eval', ou bien de n'avoir pas de CSP. Sur le site https://publications.arnaudlevy.com/, hébergé sur Netlify, tout fonctionne. Voilà les headers du fichier pagefind.js. ![image](/attachments/ddf4c68b-6317-4f83-8aa2-f1b8db076855)

image.png

130 KiB

arnaudlevy commented

2023-10-03 13:29:13 +00:00

Author

peut-on assouplir le CSP en ajoutant 'unsafe-eval' ?

quentin commented

2023-10-03 14:07:02 +00:00

Owner

Note: this issue was about a service provided by Deuxfleurs, which include a specific deployment of Garage. It's not directly about Garage as a software, that's why we are discussing in french.

J'ai supprimé les CSP injectés via HTTP, ça nous demande trop de support à ajuster en fonction de tous les cas d'usage.

Pour la suite, il va falloir que chacun mette ses CSP dans ses en-têtes HTML meta. C'est déjà le cas pour example.osuny.org, et d'ailleurs maintenant PageFind fonctionne.

Pour les futures références :

wasm devrait supporter wasm-src ou script-src. Une discussion est en cours chez Google/Chromium depuis 2019 mais ils ne se sont toujours pas mis d'accord
wasm-unsafe-eval est une solution de secours séduisante, implémentée par Chrome, Firefox, Edge, elle n'est pas supportée par Safari
unsafe-eval est donc la solution de compatibilité, qui, à mon avis, annule beaucoup de l'intéret des CSP

D'autres problèmes liés au CSP :

Une config sécurisée refuse de charger les fichiers JS qui n'ont pas le bon Content-Type. Mais en même temps, certains outils S3 du genre WinSCP ne taggent pas forcément les fichiers avec le bon Content-Type, ce qui casse le JS des utilisateurs.

Mon opinion : les CSP sont une fonctionnalité de sécurité bancale, il y a d'ailleurs plein de billets qui documentent leur edge cases, leur différences subtiles de fonctionnement entre navigateurs, etc. En plus elles sont inutiles pour un hébergement statique à la Garage car elles servent seulement à protéger des injections, ce qui ne peut pas arriver. Et enfin on peut en mettre dans le HTML. Je pense donc que Deuxfleurs devrait vraiment se mettre en retrait de ça, et laisser le soin a ses usager-es qui le souhaitent de les mettre dans leur HTML.

Note : je pense que le dépot Deuxfleurs/guichet sera plus indiqué pour tracker les bugs sur le service de site web de Deuxfleurs. Ou Deuxfleurs/nixcfg. Ou un dépôt dédié, je ne sais pas encore.

**Note:** *this issue was about a service provided by Deuxfleurs, which include a specific deployment of Garage. It's not directly about Garage as a software, that's why we are discussing in french.* J'ai supprimé les CSP injectés via HTTP, ça nous demande trop de support à ajuster en fonction de tous les cas d'usage. Pour la suite, il va falloir que chacun mette ses CSP dans ses en-têtes HTML meta. C'est déjà le cas pour example.osuny.org, et d'ailleurs maintenant PageFind fonctionne. Pour les futures références : - wasm devrait supporter `wasm-src` ou `script-src`. Une discussion est en cours chez Google/Chromium depuis 2019 mais ils ne se sont toujours pas mis d'accord - `wasm-unsafe-eval` est une solution de secours séduisante, implémentée par Chrome, Firefox, Edge, elle n'est pas supportée par Safari - `unsafe-eval` est donc la solution de compatibilité, qui, à mon avis, annule beaucoup de l'intéret des CSP D'autres problèmes liés au CSP : - Une config sécurisée refuse de charger les fichiers JS qui n'ont pas le bon Content-Type. Mais en même temps, certains outils S3 du genre WinSCP ne taggent pas forcément les fichiers avec le bon Content-Type, ce qui casse le JS des utilisateurs. Mon opinion : les CSP sont une fonctionnalité de sécurité bancale, il y a d'ailleurs plein de billets qui documentent leur edge cases, leur différences subtiles de fonctionnement entre navigateurs, etc. En plus elles sont inutiles pour un hébergement statique à la Garage car elles servent seulement à protéger des injections, ce qui ne peut pas arriver. Et enfin on peut en mettre dans le HTML. Je pense donc que Deuxfleurs devrait vraiment se mettre en retrait de ça, et laisser le soin a ses usager-es qui le souhaitent de les mettre dans leur HTML. Note : je pense que le dépot Deuxfleurs/guichet sera plus indiqué pour tracker les bugs sur le service de site web de Deuxfleurs. Ou Deuxfleurs/nixcfg. Ou un dépôt dédié, je ne sais pas encore.