Firefox (corrigé dans Nightly 59.0a1), Safari (corrigé dans Safari Technology Preview 54), Edge et Internet Explorer affichent une boîte de dialogue d'authentification si vous demandez une image et le serveur vous demande de vous authentifier avec l'authentification HTTP Basic. Cela permet à un attaquant d'afficher une boîte de dialogue d'authentification lorsque le navigateur d'un utilisateur tente de charger l'image:

• Firefox . Correction à partir de Nightly 59.0a1, mais l'avertissement présent dans la dernière version stable:

  

• Safari . Corrigé à partir de Safari Technology Preview 54, mais le modal est toujours présent dans la dernière version stable. Notez qu'il s'agit d'une boîte de dialogue modale et que le reste du site Web est grisé. "Vos informations de connexion seront envoyées en toute sécurité" est également techniquement vrai mais peut donner à un utilisateur imprudent une mauvaise impression:

  

• IE11 . Une boîte de dialogue Windows native verrouille tout le navigateur:

  

Si vous créez le domaine une très longue chaîne de a \ ta \ ta \ t ... a \ t , IE11 se verrouille complètement.

Un nom de domaine et un domaine bien choisis peut inciter les utilisateurs à envoyer leurs noms d'utilisateur et mots de passe au serveur d'un attaquant, ou rendre votre site Web complètement inaccessible.

Comme le dit Anders: Blender fait un très bon point sur les dialogues d'authentification, et multithr3at3d a raison sur les attributs on. De plus, Anders ajoute des arguments sur la balise a et Matija a un bon lien sur l'exploitation des bibliothèques faisant le rendu.

Pourtant, personne a encore parlé de SVG.

Tout d'abord, supposons que toutes les entrées et sorties sont correctement nettoyées, donc les astuces avec onerror / onload sont pas possible. Et que nous ne sommes pas intéressés par le CSRF. Nous sommes après XSS.

La première préoccupation concernant <img src = est qu'il ne suit pas la même politique d'origine. Mais c'est probablement moins dangereux qu'il n'y paraît.

Ce que fait le navigateur pour afficher une balise < img >

< img src = "http: // domaine / image .png "> est assez sûr car le navigateur n'invoquera pas un analyseur (par exemple un analyseur XML ou HTML), il sait que ce qui va venir est une image (gif, jpeg, png).

Le navigateur effectuera la requête HTTP, et il lira simplement le MIME de ce qui est venu (dans l'en-tête Conetent-Type , par exemple image / png ). Si la réponse n'a pas de Content-Type , plusieurs navigateurs devineront en fonction de l'extension, mais ils ne devineront que les MIME d'image: image / jpeg , image / png ou image / gif (tiff, bmp et ppm sont douteux, certains navigateurs peuvent avoir un support limité pour les deviner). Certains navigateurs peuvent même essayer de deviner le format d'image basé sur des nombres magiques, mais encore une fois, ils n'essaieront pas de deviner les formats ésotériques.

Si le navigateur peut correspondre au MIME (éventuellement deviné), il charge le rendu correct bibliothèque, les bibliothèques de rendu peuvent avoir un débordement mais c'est une autre histoire. Si le MIME ne correspond pas à une bibliothèque de rendu d'image, l'image est supprimée. Si l'appel de la bibliothèque de rendu échoue, l'image est également supprimée.

Le navigateur n'est même jamais proche d'un contexte d'exécution (script). La plupart des navigateurs n'entrent dans le contexte d'exécution qu'à partir de l'analyseur javascript, et ils ne peuvent accéder à l'analyseur javascript qu'à partir de application / javascript MIME ou des analyseurs XML ou HTML (car ils peuvent avoir des scripts intégrés).

Pour exécuter XSS, nous avons besoin d'un contexte d'exécution. Entre SVG.

Utilisation d'< img src = "domain / blah / blah / tricky.svg" >

Aïe, aïe aïe. SVG est un format graphique vectoriel basé sur XML, il appelle donc l'analyseur XML dans le navigateur. De plus, SVG a la balise <script> ! Oui, vous pouvez intégrer du javascript directement dans SVG.

Ce n'est pas aussi dangereux qu'il y paraît au début. Les navigateurs qui prennent en charge SVG dans les balises <img> ne prennent pas en charge les scripts dans le contexte. Idéalement, vous devriez utiliser SVG dans les balises <embed> ou <object> où les scripts sont pris en charge par les navigateurs. Pourtant, ne le faites pas pour le contenu fourni par l'utilisateur!

Je dirais qu'autoriser SVG à l'intérieur de <img src = peut être dangereux:

• Un analyseur XML est utilisé pour analyser le SVG, qu'il soit à l'intérieur de la balise <img> ou <object> . L'analyseur est certainement modifié avec certains paramètres pour ignorer les balises <script> dans le contexte <img> . Pourtant, c'est assez moche, c'est mettre sur liste noire une balise dans un certain contexte. Et la mise sur liste noire est une mauvaise sécurité.

• <script> n'est pas le seul moyen de réaliser le contexte d'exécution en SVG, il existe également le onmouseover (et famille) événements présents en SVG. C'est encore une fois difficile de mettre sur liste noire.

• L'analyseur XML dans les navigateurs a souffert de problèmes dans le passé, notables avec les commentaires XML autour des blocs de script. SVG peut présenter des problèmes similaires.

• SVG a un support complet pour les espaces de noms XML. Aïe encore. xlink: href est une construction complètement valide en SVG et le navigateur dans le contexte de l'analyseur XML la suivra probablement.

Donc oui, SVG s'ouvre plusieurs vecteurs possibles pour réaliser le contexte d'exécution. Et de plus, c'est une technologie relativement nouvelle et donc pas bien durcie. Je ne serais pas surpris de voir des CVE sur la gestion des SVG. Par exemple, ImageMagick a rencontré des problèmes avec SVG.