Vulnérabilité des balises IMG
Est-il sûr d'afficher des images de domaines arbitraires? C'est à dire. disons que j'ai une image sur ma page:
<img src="http://badguy.com/image.gif" />
Et si image.gif Renvoie un vecteur d'attaque js, mais pas l'image? Y a-t-il des vecteurs connus?
J'ai essayé de servir javascript:alert(1) ou le même, mais encodé en base64. Mais sans aucune chance. Des idées?
Il y avait autrefois une "vulnérabilité" où l'image pouvait envoyer un HTTP 401 Unauthenticated réponse, ce qui déclencherait un écran de connexion pour l'utilisateur. Si vous le définissez comme avatar de forum, cela ouvrirait une fenêtre de connexion pour toute personne visitant une page où votre avatar apparaît. De nombreuses personnes tenteront alors de se connecter avec une combinaison de nom d'utilisateur et de mot de passe, probablement celle de leur compte de forum.
Un de mes amis l'a trouvé il y a quelques années, mais de nos jours cela ne semble plus fonctionner. Au moins, je ne pouvais pas facilement le reproduire il y a quelques mois. Edit: j'avais tort, cette attaque est toujours possible!/Edit
Quant aux attaques XSS de cette façon, vous êtes en sécurité. Le navigateur interprétera ou devrait toujours interpréter cela comme une image, peu importe ce qu'il contient ou les en-têtes qu'il envoie. Vous pouvez personnaliser l'image en fonction de la demande (servir une petite image au logiciel du forum en pré-vérifiant l'image afin qu'elle ne la réduise pas, puis qu'elle soit grande pour tout le monde). Ou alimentez le navigateur beaucoup de données gif jusqu'à épuisement de la mémoire ou quelque chose. Mais il n'y a pas vraiment de grandes vulnérabilités ici qui permettent l'exécution de code à distance pour autant que je sache.
Ce que vous n'êtes que modérément sûr, ce sont les attaques CSRF. L'image peut émettre un HTTP 302 Moved Temporarily réponse et lien vers un nouvel emplacement. Par exemple, il pourrait créer un lien vers, je ne me souviens pas de l'URL spécifique, quelque chose comme https://accounts.google.com/logout et vous déconnecter de google (cela a fonctionné il y a quelques mois). Ou, un peu plus malicieusement: http://example.com/guestbook.php?action=post&message=spam-url.example.com.
Pour autant que je sache, seules les demandes GET peuvent être effectuées de cette manière. Ou si l'image était à l'origine chargée en tant que POST, je suppose qu'elle pourrait également rediriger le POST, mais pas changer les données POST. C'est donc assez sûr.
Enfin, si l'attaquant contrôle les URL des avatars de forum par exemple (comme dans les forums SMF), il est possible d'obtenir des informations des visiteurs telles que leur adresse IP. J'ai écrit un outil il y a quelque temps qui utilisait le action=who page de SMF pour lier les adresses IP aux noms d'utilisateur. Quand j'ai commencé à afficher cela aux utilisateurs (afficher "Bonjour $ nom d'utilisateur avec IP: $ IP" dans l'image), tout l'enfer s'est déchaîné. "Comment pourriez-vous savoir cela?!" Ils étaient principalement des techniciens débutants ou mi-adolescents, donc ils savaient ce qu'était une adresse IP, mais ils ne l'ont pas fait Je sais que je ne pouvais pas les pirater avec ça. Il est cependant considéré comme des informations personnellement identifiables, du moins aux Pays-Bas, de sorte que les administrateurs n'étaient pas très satisfaits de cette pratique. Si vous ne l'affichez pas, personne ne le saura jamais.
Remarque: Si ce message semble écrit à la hâte, il l'est. Je suis à peine réveillé aussi. Peut-être que je vais le nettoyer demain si c'est trop de narration et pas assez de faits concrets et de vulnérabilités. J'espère que cela a quand même aidé!
La balise IMG tentera d'interpréter les données comme une image, donc Javascript ne sera pas exécuté.
Il sera possible d'envoyer une image qui, une fois décodée, nécessitera d'énormes quantités de mémoire ("bombe PNG"), et il est possible que les routines graphiques elles-mêmes soient vulnérables aux contenus malveillants (une image soigneusement conçue qui, une fois décodée, déclenche l'exécution du code embarqué). Il y avait une telle vulnérabilité il y a près de dix ans , et bien que peu probable, une autre pourrait apparaître.
[~ # ~] mise à jour [~ # ~] : un autre did . Et n autre , et celui-ci a un score CVSS de 9,3 - " Il y a un compromis total de l'intégrité du système. Il y a une perte complète de protection du système, résultant dans tout le système compromis "
Puis le HTTP_REFERER tag permettra au propriétaire du site d'image de savoir quelles pages ont été visitées, et grâce à l'utilisation de cookies de suivi, certaines divulgations d'informations sont possibles (par exemple, le site malveillant héberge une image qui est partagée entre les sites A, B et C Le propriétaire de l'image peut voir qu'un utilisateur donné sur le site A est la même personne qu'un autre utilisateur du site B, car l'image a créé un cookie lorsqu'elle est utilisée sur le site A, et maintenant le même cookie arrive d'un utilisateur du site B). Selon le scénario, cela peut être indésirable.
En intégrant dans les parties image de la conception du site hôte, un attaquant pourrait faire croire à l'utilisateur que le site héberge du contenu qui n'est pas réellement là. Cela nécessite que le HTML/CSS soit vulnérable à un changement soudain de la taille de l'image. Par exemple, un site boursier peut afficher, au lieu d'une bannière 200x80, une bannière 200x600 dont les lignes les plus hautes sont identiques à la bannière d'origine, et la partie ci-dessous est conçue pour simuler le site boursier et est "repoussée" sur un stock ticker, et reproduit le même ticker de stock - mais avec des valeurs différentes. Un utilisateur imprudent pourrait alors être amené à croire que les chiffres des stocks sont totalement faux. Si suffisamment d'utilisateurs sont convaincus, cela pourrait permettre une sorte de schéma de "pompage et vidage".
Une variation de ce qui se produirait souvent se produit lorsque vous liez l'image sans autorisation appropriée. Le propriétaire du site Web, qui prend en charge le transport et la fourniture de l'image aux vos téléspectateurs, a la possibilité de changer l'image avec quelque chose de complètement différent . Cela est parfois fait exprès au préalable, c'est-à-dire qu'une image "juteuse" est semée dans les forums appropriés (par exemple, une purée contre une équipe de football?), Puis est commutée avec quelque chose avec un contenu opposé (la même chose avec les Arch-rivaux de cette équipe) . Pour plus de plaisir, le webmestre de pêche à la traîne peut enregistrer les adresses IP d'origine qui ont téléchargé l'image, et continuer à envoyer eux l'image d'origine. Donc les fans de l'équipe A vont faire la publicité d'une framboise contre la leur équipe, et ne pas comprendre pourquoi tout le monde rit - à chaque fois ils regardez l'image, ils voient il se moque de l'équipe B. Ce qui sert d'alerte: ne présumez pas que l'image que VOUS voyez est la même que VOS UTILISATEURS voient .
JavaScript lui-même ne sera pas exécuté, même si le serveur distant change MIME Content-Type à text/javascript, car les navigateurs attendent déjà certains types MIME dans la balise IMG. Cela ne signifie pas vraiment qu'ils sont sûrs à utiliser, cependant.
Un fil que je vous suggère de lire est est-il sûr de permettre que des images externes soient jointes à un blog ou à un contenu Web? . En bref, les serveurs à partir desquels vous liez des images externes peuvent toujours lire toutes les données de la requête HTTP qui leur a été envoyée par le navigateur de l'utilisateur final (à savoir l'adresse IP de la requête, la chaîne de l'agent utilisateur, la version du protocole et en provenance non HTTPS demandez également d'autres en-têtes de requête, parmi lesquels referer chaîne URL et bien sûr les cookies HTTP non sécurisés).
Le serveur distant pourrait également générer des images de manière dynamique, créant potentiellement d'autres causes de préoccupation (contenu inapproprié, peur de la propagande en ajoutant des informations de demande de l'utilisateur final telles que l'adresse IP, ...), ou simplement suivre l'activité des utilisateurs sur vos serveurs en inspectant les en-têtes de demande HTTP décrits plus tôt, ou abandon cookies de suivi tiers avec leur réponse. L'exposition des URL dans la chaîne referer de requêtes HTTP non sécurisées est souvent négligée et peut exposer les adresses Web de votre serveur que vous pourriez ne pas aimer vraiment (emplacement CMS, données de session URL, .. .). Il en va de même pour les cookies non sécurisés qui ne sont pas limités à un seul domaine (emplacement) et peuvent être lus et même écrasés par un tiers.
De plus, le code malveillant peut se propager à travers des images spécialement conçues sur les systèmes clients qui n'ont pas été correctement corrigés. L'un des exploits les plus connus était le bogue GDI + qui pouvait permettre l'exécution de code à distance sur les versions antérieures non corrigées de Windows. Il existe également autres exploits similaires , dont certains ne sont toujours pas correctement traités sur tous les systèmes.
Parmi les derniers exploits de ce type, le déclenchement de code Java (pas JavaScript) à partir d'une image SVG spécialement conçue) est possible sur certains navigateurs. [1][2] :
Exploit-DB - Déclenchement Java Code à partir d'une image SVG :
SVG est un format de fichier basé sur XML pour les images statiques ou animées. Certaines spécifications SVG (comme SVG 1.1 et SVG Tiny 1.2) permettent de déclencher du code Java lorsque le fichier SVG est ouvert.
et
Metasploit - Squiggle 1.7 SVG Browser Java Exécution du code :
Ce module abuse du support SVG pour exécuter Java Code dans le navigateur Squiggle inclus dans le framework Batik 1.7 via un fichier SVG spécialement conçu référençant un fichier jar. Pour obtenir l'exécution de code arbitraire, le navigateur doit remplir les conditions suivantes: (1) Il doit prendre en charge au moins la version 1.1 ou plus récente de SVG, (2) Il doit prendre en charge Java code et (3) La vérification "Appliquer le script sécurisé" doit être désactivée Le module a été testé sur les plates-formes Windows et Linux
Et un peu plus sur les exploits SVG possibles peuvent être lus dans le thread Exploits ou autres risques de sécurité avec le téléchargement SVG? .
Donc, en bref, ce n'est pas trop sûr et dépend probablement de votre confiance sur le ou les serveurs distants à partir desquels vous lieriez des images pour ne pas l'exploiter.
Oui, tu es en sécurité.
Bien sûr, la page que vous recevez lorsque vous clic droit> Afficher l'image peut être malveillante, mais aucun script ne sera exécuté dans le contexte de votre site Web.
De plus, n'oubliez pas que le propriétaire du site Web de l'image peut suivre vos visiteurs sur toutes les pages où l'image est intégrée.
Une demande IMG est une demande GET à un serveur arbitraire, qui peut être dangereux
La réponse du serveur peut supprimer ou écraser les cookies qui peuvent affecter le fonctionnement de votre navigateur.
Plus d'informations
Stackoverflow a été mordu par ce bug, où la déconnexion REST API était accessible par une simple demande GET.
Je pense que le scénario s'est déroulé comme suit:
- Un spammeur a posté du spam sur une page donnée.
- Sur cette page, ils ont inclus un get pour
/users/logoutdans une balise IMG - Les cookies d'authentification pour l'utilisateur ont été supprimés via les en-têtes HTTP.
- Chaque fois qu'un administrateur ou un modérateur tentait de supprimer le SPAM, il était déconnecté.
Cela fait partie de la raison pour laquelle il existe une page de déconnexion lorsque vous cliquez sur "se déconnecter" sur SO.
En plus: Même si SO est un site HTTP (pas de "s"/SSL), je pense que les cookies sécurisés seraient vulnérables