Broken images in XSS attacks

Many websites discuss broken images being good warning signs of a possible XSS attack in the pages source code. My question is why so many attackers allow this to happen. It doesn't seem like it would be very much more trouble for an attacker to use an iframe or an unassuming picture to hide their persistent script behind. I could be wrong in assuming that broken images are very common with XSS. Thanks for the help!

Edit: I think XSS could be a misnomer in this case. I understand why an image tag that points to a java script file wouldn't display and be too much trouble to display. I think my question is more related to instances of files uploaded to the server with malicious code in them. I guess that's sort of a second question actually--is that actually XSS or more like an exploit of insecure object references by the server (going by OWASP terms)?

Edit: Here is a nice article describing XSS in detail. It mentions broken images, but it also discusses how to avoid them. I can't find 开发者_运维百科any articles mentioning specific attacks with broken images. I recall reading about a few phishing attacks through email however (in these cases you are absolutely correct about CSRF, Daniel.

The websites that you have been reading may be referring to Cross-Site Request Forgery attacks (CSRF; CWE-352). CSRF attacks are commonly carried out with "broken images" because (1) browsers load images automatically (so the browser automatically makes an HTTP request on behalf of the visitor) and (2) many websites allow users to add images to user-contributed content.

Imagine that a website allowed users to post comments on a blog, and the blog software allowed users to add images to their comments by specifying the URL of an image. There are likely various admin functions of the blog software that are invoked by requesting certain URLs. For example, a comment might be deleted by anyone who is logged in as an administrator if the admin "visited" /comments/delete/# (where "#" is an ID of the particular comment to be deleted). A malicious non-admin will not be able to delete a comment, say comment 7754, by visiting /comments/delete/7754 because he or she is not authenticated. However, the malicious user might try adding a new comment with the content consisting only of the "image" at /comments/delete/7754. If an admin were to subsequently view the comment (simply view the page containing the malicious user's comment), then the browser would automatically request the "image" at /comments/delete/7754. This could cause comment 7754 to be deleted because the admin is logged in.

This example of deleting comments gives you an idea of how some CSRF attacks work, but note that the effects can be a lot more sinister. The CWE page that I linked to references actual CSRF issues with various software that allowed things like privilege escalation, site settings manipulation, and creation of new users. Also, simply requiring POST for all admin functions does not make a website immune to CSRF attacks because a XSS attack could dynamically append a specially-constructed form element to the document and programmatically submit it.