All major browsers are still vulnerable to these attacks. Tons of ways of using img tags are still around.. For example...

<img src='#' onerror=alert(1) />

Look for RSnake's xss cheatsheet, those are just some vectors. By the way, I've heard he's coming up with a new version of his cheatsheet soon.

Like Anders says: Blender makes a very good point about authentications dialogs, and multithr3at3d is right about the on attributes. Moreover, Anders add argues about the a tag and Matija have a good link about exploiting libraries doing the rendering.

Yet, no one talked about SVG yet.

First of all let's assume that all input and output is properly sanitized so tricks with onerror/onload are not possible. And that we are not interested in CSRF. We are after XSS.

The first concern about <img src= is that it does not follow same origin policy. But that is probably less dangerous than it sounds.

What the browser does to render an < img > tag

< img src="http://domain/image.png" > is pretty safe because the browser will not invoke a parser (e.g. an XML or HTML parser), it knows that what will come is an image (gif, jpeg, png).

The browser will perform the HTTP request, and it will simply read the MIME of what came (in the Conetent-Type header, e.g. image/png). If the answer does not have a Content-Type several browsers will guess based on the extension, yet they will only guess image MIMEs: image/jpeg, image/png or image/gif (tiff, bmp and ppm are dubious, some browsers may have a limited support to guess them). Some browsers may even try to guess the image format based on magic numbers, but then again they will not try to guess esoteric formats.

If the browser can match the (possibly guessed) MIME it loads the correct rendering library, rendering libraries may have an overflow but that is another story. If the MIME does not match against an image rendering library the image is discarded. If the rendering library call fails the image is discarded as well.

The browser is never even close to an execution (script) context. Most browsers enter execution context only from the javascript parser, and they can only reach the javascript parser from the application/javascript MIME or from the XML or the HTML parsers (since they may have embedded scripts).

To perform XSS we need an execution context. Enters SVG.

Using < img src="domain/blah/blah/tricky.svg" >

Ouch, ouch ouch. SVG is an XML based vector graphic format, therefore it invokes the XML parser in the browser. Moreover SVG has the <script> tag! Yes, you can embed javascript directly into SVG.

This is not as dangerous as it sounds at first. Browsers that support SVG inside <img> tags do not support scripting inside the context. Ideally you should use SVG inside <embed> or <object> tags where scripting is supported by browsers. Yet, do not do it for user provided content!

I would argue that allowing SVG inside <img src= may be dangerous:

• An XML parser is used to parse the SVG, whether it is inside the <img> or <object> tag. The parser is certainly tweaked with some parameters to ignore <script> tags in the <img> context. Yet, that is quite ugly, it is blacklisting a tag in a certain context. And blacklisting is poor security.

• <script> is not the only way to achieve execution context in SVG, there are also the onmouseover (and family) events present in SVG. This is again tricky to blacklist.

• The XML parser in browsers did suffer from problems in the past, notable with XML comments around script blocks. SVG may present similar problems.

• SVG has full support for XML namespaces. Ouch again. xlink:href is a completely valid construct in SVG and the browser inside the XML parser context will likely follow it.

Therefore yes, SVG opens several possible vectors to achieve execution context. And moreover, it is a relatively new technology and therefore not well hardened. I would not be surprised to see CVEs on SVG handling. For example ImageMagick had problems with SVG.

No, in modern browsers no XSS is possible via the style or src attribute of an <img> tag.

So neither of these would execute the JS code in any up-to-date browser:

<img src="javascript:alert(1)">
<img src="x.jpg" style=background-image:url('javascript:alert(2)')">

Support for Javascript in CSS attributes has long been abandoned. You can find some older references about it here.

Analysis of your example code

location.hash always starts with a # symbol. Since this character is illegal in JS and not a valid beginnig of a new URL, no XSS would be possible in the first place. (For instance, eval(location.hash) always produces a syntax error.)

Let's assume, you ignore the # and location.hash could really contain any string you want.

Then this security check is flawed:

(location.hash.indexOf('javascript:') !== 0)

An attacker could still construct a URL starting with JaVaScRiPt:. Also, it's risky to assume that no implementation would ever allow leading spaces or control characters (e.g. \t\x00javascript:). And what about URL-encoding? A payload starting with javascript%3a would pass your filter. Also, do you want to allow the data: protocol? If you like to restrict the URL to absolute locations, you could whitelist the beginnings http:// and https:// instead of blacklisting javascript:.

This is fine:

img.src='some/local/path/'+location.hash;

Even if the src attribute was susceptible to script code, your prefix some/local/path/ ensures that it cannot be turned into a JS URL. However, an attacker could specify any relative path to an image file on the same server, which you might find undesirable.

NB: This is about constructing malicious javascript: URLs. If you want to use user-controlled values like location.hash for HTML output or a different context, you have to properly sanitize the string.

No, it's not. Although SVG files can contain JS (see this), these will only get executed if:

1. the user directly visits the .svg file in their browser
2. the image is embedded within <embed> tags.

Modern browsers will never execute scripts in SVGs if it's within <img> tags.

And even in the two cases above, the server can provide CSP headers that stop the execution of such scripts.

What if the user's string is 'no" onerror="alert(0)'?

This'll expand to:

<img src="http://no" onerror="alert(0)">

The safest way is to use document.createElement and assign the src attribute. Using innerHTML isn't a very safe approach

var img = document.createElement('img');
img.src = ...;

The HTML spec states that the src attribute must point to a valid image resource that is neither paged nor scripted.

The src attribute must be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted.

...

However, these definitions preclude SVG files with script, multipage PDF files, interactive MNG files, HTML documents, plain text documents, and the like.

Whether a future browser complies with this or not is a different story.

The risk is pretty low, assuming some basic cautions. One threat would be to have an image that is much larger than intended and basically overlays the page with some sort of phishing content. That's easily avoided by limiting the image size, though. Another would be to use a "watering hole" attack, in the event that a vulnerability in an image parser is discovered; if your site is popular, attackers might post links to their malicious exploit image on your site to try to catch lots of victims. Finally, there's reputational risk; if somebody wants to post shock images, racist symbology, cartoons of the prophet Muhammad, or pornography on your site (and especially if there's any risk of it being less than 100% clear who is responsible for the image), some people will be driven away from your site and others will take it as incentive to vigilante action against you. There's also decompression bombs, which are small files in compressed formats that grow to extreme size when decompressed and can cause denial-of-service for users; some image formats present some risk from these, and your users won't appreciate it if your site crashes their browser.

To be clear, these issues in general are the kinds of things you run into when trying to allow users to show images; they aren't unique to allowing users to specify the <img src=" value.