web-dev-qa-db-fra.com

L'inclusion du schéma de données dans votre politique de sécurité du contenu est-elle sûre?

J'ai une application Cordova qui transforme certaines images en base64. Cela viole CSP avec ce message:

Refus de charger les données de l'image: image/svg + xml; charset = US-ASCII,% 3C% 3Fxml% 20version% 3D% 221.0% 22% 20encod… E% 3C% 2Fg% ...% 3C% 2Fsvg% 3E 'car il viole la directive de politique de sécurité du contenu suivante: "default-src' self '". Notez que 'img-src' n'a pas été explicitement défini, donc 'default-src' est utilisé comme solution de rechange.

Selon cette réponse , je peux simplement ajouter data: à ma méta Content-Security-Policy, mais j'aimerais beaucoup savoir si c'est sûr? data: ne précise pas l'origine et je crains donc que ce ne soit pas sûr.

27
Martin Verner

C'est une excellente question, et je vous félicite d'avoir pris le temps d'y réfléchir du point de vue de la sécurité plutôt que de mettre en œuvre la solution à partir du lien que vous avez envoyé.

Oui, comme vous l'avez craint, utilisez data: dans une directive CSP n'est pas sûr, car cela permet d'ouvrir les vulnérabilités XSS en tant que données: peut gérer n'importe quel URI. Ceci est expliqué dans Documentation CSP de Mozilla.

Vous pouvez réduire la surface d'une attaque XSS potentielle en changeant la directive data: en:

img-src 'self' data:image/svg+xml

Cependant, comme meilleure pratique, je m'efforcerais de résoudre le problème racine des images fournies en base64 et de voir si cela peut être fait d'une autre manière afin de ne pas nécessiter de modification de la directive CSP.

13
Herringbone Cat
  1. La note sur la mise en liste blanche du protocole de données qui est référencé dit

    data: permet aux données: les URI d'être utilisés comme source de contenu. Ce n'est pas sûr; un attaquant peut également injecter des données arbitraires: les URI. Utilisez-le avec parcimonie et certainement pas pour les scripts.

    Ce n'est pas dans une partie spécifique aux risques d'uris de données dans les images , et je n'ai vu aucune preuve substantielle que les uris de données dans les images peuvent exécuter du code dans un navigateur moderne à tous égards, nevermind XSS une page.

    Dans certains contextes, une image SVG peut exécuter du code Javascript, mais ce sont soit des contextes enfants tels que <iframe>, <object> ou <embed> éléments, ou une partie directe du DOM hôte, c'est-à-dire <svg> éléments.

    MDN appelle explicitement que <img> les SVG intégrés ne peuvent pas exécuter Javascript, ainsi que d'autres restrictions de sécurité, en disant

    • JavaScript est désactivé.
    • Les ressources externes (par exemple, les images, les feuilles de style) ne peuvent pas être chargées, bien qu'elles puissent être utilisées si elles sont intégrées dans les données: les URI.
    • :visited-link les styles ne sont pas rendus.
    • Le style de widget natif de la plateforme (basé sur le thème du système d'exploitation) est désactivé.
  2. Il ne semble pas possible de spécifier un MIME dans le cadre du data: déclaration de mise en liste blanche du protocole suggérée comme atténuation possible. La seule directive de politique de sécurité du contenu que j'ai vue capable de restreindre le type MIME est plugin-types, qui restreint uniquement pour <object> et <embed> (voir documentation CSP générale ).

Je suis d'accord avec la réponse acceptée en ce qui concerne le fait que si vous n'avez pas à utiliser data-uris, et peut le faire avec peu de douleur, il est plus facile de simplement garder votre CSP et de ne pas l'utiliser. Cependant, si vous travaillez avec des images, c'est généralement une énorme douleur.

24
zemnmez