Images rompues dans les attaques XSS

Question

De nombreux sites Web traitent des images cassées comme de bons signes avant-coureurs d'une éventuelle attaque XSS dans le code source des pages. Ma question est de savoir pourquoi tant d'attaquants permettent cela. Il ne semble pas que ce serait beaucoup plus difficile pour un attaquant d'utiliser un iframe ou une image sans prétention pour cacher son script persistant. Je pourrais me tromper en supposant que les images cassées sont très communes avec XSS. Merci pour l'aide!

Editer: Je pense que XSS pourrait être un abus de langage dans ce cas. Je comprends pourquoi une balise d'image qui pointe vers un fichier de script Java ne s'afficherait pas et serait trop difficile à afficher. Je pense que ma question est plus liée à des instances de fichiers téléchargés sur le serveur avec du code malveillant. Je suppose que c'est en quelque sorte une deuxième question - est-ce XSS ou plutôt un exploit de références d'objets non sécurisées par le serveur (selon les termes OWASP)?

Editer: Voici un joli article décrivant XSS en détail. Il mentionne des images brisées, mais il explique également comment les éviter. Je ne trouve aucun article mentionnant des attaques spécifiques avec des images cassées. Je me souviens avoir lu quelques attaques d'hameçonnage par e-mail (dans ces cas, vous avez absolument raison sur CSRF, Daniel.)

Answer 1

Les sites que vous avez lus peuvent faire référence à des attaques de type "Cross-Site Request Forgery" (CSRF; CWE-352) Les attaques CSRF sont généralement effectuées avec des "images cassées" car (1) les navigateurs chargent automatiquement les images (le navigateur fait automatiquement une requête HTTP au nom du visiteur) et (2) de nombreux sites permettent aux utilisateurs d'ajouter des images aux contributions des utilisateurs. Imaginez qu'un site web permette aux utilisateurs de publier des commentaires sur un blog, et que le logiciel du blog permette aux utilisateurs d'ajouter des images à leurs commentaires en spécifiant l'URL d'une image. sont invoqués en demandant certaines URL. Par exemple, un commentaire peut être supprimé par toute personne connectée en tant qu'administrateur si l'administrateur a "visité" /comments/delete/# (où "#" est l'ID du commentaire particulier à supprimer). Un non-administrateur malveillant ne sera pas en mesure de supprimer un commentaire, disons le commentaire 7754, en visitant /comments/delete/7754 car il n'est pas authentifié. Toutefois, l'utilisateur malveillant peut essayer d'ajouter un nouveau commentaire avec le contenu constitué uniquement de "l'image" au /comments/delete/7754. Si un administrateur devait ensuite afficher le commentaire (il suffit de voir la page contenant le commentaire de l'utilisateur malveillant), le navigateur demandera automatiquement l'image au /comments/delete/7754. Ce pourrait cause de commentaire 7754 à supprimer parce que l'administrateur est connecté.

Cet exemple de supprimer les commentaires que vous donne une idée de la façon dont certaines attaques CSRF fonctionnent, mais notez que les effets peuvent être beaucoup plus sinistre. La page CWE que j'ai liée à fait référence à des problèmes CSRF réels avec divers logiciels qui permettaient des choses comme l'escalade de privilèges, la manipulation des paramètres du site et la création de nouveaux utilisateurs. En outre, le simple fait d'exiger POST pour toutes les fonctions d'administration ne rend pas un site Web immunisé contre les attaques CSRF car une attaque XSS peut ajouter dynamiquement un élément form spécialement construit au document et le soumettre par programmation.