What could an "<img src=" XSS do?
Most WAFs when blocking XSS will block obvious tags like
iframe, but they don't block
Theoretically, you can
img src='OFFSITE URL', but what's the worse that can happen? I know you can steal IPs with it, but is that it?
Example of what @grochmal means with the rendering libraries: you can attack some unpatched very old versions of Windows with the Metafile vulnerability present.
`` That will send a GET request to that domain, passing any cookies, like sessions, you have stored. If that works, it is mostly the fault of your bank, because those actions should not occur in a GET request.
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
atag 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
onloadare 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
image/png). If the answer does not have a
Content-Typeseveral browsers will guess based on the extension, yet they will only guess image MIMEs:
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.
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
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
<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
<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:hrefis 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.
This is one of the reasons why I subscribe to "deny all," and then some. :) Catches edge-cases like this.
Accepted because this seems like definitely the "worst" you can do with this XSS.
@user1910744 - Well, SVG is quite new and evolving very fast. Although I am not aware of any browser related CVE for SVG, the number of things that can go wrong is just so big that there must be something. Had I managed to secure some funding to go bug hunting in the browser security context, SVG would be the first place I'd look into.
Your last point about the `xlink:href` attribute is already covered by the specs, no external content can be loaded from an img content => xlink:href in an `` tag can only reference inner resources.
@MatthieuM. - The XML parser is the one used to process XHTML, a browser is either in HTML (html parser) or XML (xml parser) mode before entering execution context. On the `< img >` and `xlink:href` is again a question of tweaking the parser: Inside `< object >` it is allowed to go outside fetch things outside, therefore it is blacklisting the `< img >` context inside parser (if the parser can be fooled you can get out, not arguing that the parser can be fooled now but SVG is still evolving).
@grochmal: Thanks. I still don't see why they would need to blacklist tags when most libraries seem to be implicitly about whitelisting (by adding callbacks that react on certain tag explicitly), even if they reuse the same XML parser that is used for XHTML (which is not necessary, since for XHTML you might want something more specific). I suppose "it just works" came again good development & security practices if this is the case :x
@MatthieuM. - I mean blacklisting because the code `we are parsing SVG => found => execute` exists, because it is a valid action inside `<object>`, it is only invalid inside `<img>`. And yes, most browsers used (still use?) the XML parser for XHTML, and then fallback to the HTML parser if that failed, which gave its own numbers of issues. Yet, in general, the point is that allowing an XML based format (that can perform scripting) inside `<img>` and just limiting it to not perform the scripting in this specific context is silly. Too many things can go wrong.