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?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
Like Anders says: Blender makes a very good point about authentications dialogs, and korockinout13 is right about the on attributes. Moreover, Aders 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
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.
< 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/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.
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: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.
Firefox (fixed in Nightly 59.0a1), Safari (fixed in Safari Technology Preview 54), Edge, and Internet Explorer display an authentication dialog if you request an image and the server asks that you authenticate with HTTP Basic authentication. This allows an attacker to display an authentication dialog when a user's browser tries to load the image:
Firefox. Fixed as of Nightly 59.0a1, but the warning present in latest stable release:
Safari. Fixed as of Safari Technology Preview 54, but the modal is still present in the latest stable release. Note that it's a modal dialog and the rest of the website is grayed out. "Your login information will be sent securely" is also technically true but may give a careless user the wrong impression:
IE11. A native Windows dialog locks up the whole browser:
If you make the
realm a really long string of
a\ta\ta\t...a\t, IE11 completely locks up.
A well-chosen domain name and realm can trick users into sending their usernames and passwords to an attacker's server, or make your website completely inaccessible.
<img src=http://evil.com is not too much of an issue, but
Okay, how about this: (You should probably stand back.)
Oh I know, right? What a monster!
Well it could be, if you are using SMB...
This affects Internet Explorer, including Microsoft Edge. It should be noted that this does not affect Chrome or Mozilla browsers. IE attempts to auto-authenticate to the attacker's website, passing username and hashed NTLM password to the remote server, and yes even over the internet (!!).
I therefore conclude that absolutely no one should be using an IMG tag, ever.
Yes, but is it XSS? No, it does not necessarily launch or constitute an XSS attack, that I am aware of. Although it may be launched from one, it is not a requirement. Does cross-network count?
I think by "img XSS" you mean "site that allows arbitrary values for the
src="" attribute of
<img /> elements".
...in which case the main risk is of Cross Site Request Forgery (CSRF) as it means an attacker can make a target make an arbitrary
GET request, the canonical example being the "poorly-coded bank website makes money transfers using
However it does not necessarily have to be a Cross Site Request Forgery - I imagine the main type of site that allows for user-supplied
<img /> elements is a web-forum - and web-forums tend to have admin control panels in the same website - so if any "useful" admin or moderator actions could be invoked via GET then that is another possibility - but this still falls under the CSRF umbrella.
The D's answer points out that a
GET can be used to issue commands both cross site and on the same site. I want to expand on that notion because saying "It's a
GET request - be careful" doesn't usually manage to convey why that might be a problem.
One attack that can be done that other answers have not covered is denial of service. Consider the following:
You are on a forum, and somebody posts a message which has an embedded
<img src="/logout" /> - this leads to everyone being logged out when the image gets loaded. Now, none of the users can use the forum, as long as they see that page.
This is a relatively trivial example, but nonetheless it's a potential problem. To show how it could be more of a problem, imagine it's some sort of news site or other that displays user comments on the main page and after login, you are redirected there. Now nobody can ever login without being logged out immediately.
So far, these are not cross site attacks. They can relatively simply be turned into that, though - imagine if Facebook or another popular website allows arbitrary source for images and you post the following
<img src="http://yourdomain.com/logout" /> - people will be logged out without even having to be on
yourdomain.com. This can range from annoying ("Ugh, the website asks for my password again") to potentially problematic ("Wait, where did all my unsaved work go?").
It's entirely possible that it's not even logout that the image targets - what if it's
http://yourdomain.com/deleteMyUser which makes users "leave" the website without their agreement? Or maybe the more plausible
http://yourdomain.com/findPrimes?count=9001 which will eventually overload your server to do heavy calculations?
What I find most irritating about this sort of attack is that it's not even a problem with
img tags themselves - even if your webapp is careful with images, somebody else's might not be. The core of the problem is that the logout link (or whatever resource an attacker might exploit) can just be invoked via
GET and the image is merely vector to make browsers issue that
GET. Trouble is that it's entirely not obvious to a lot of developers that is the case.
In addition to what all other answers already mentioned, image itself might be deliberately modified in such a way that parsing it exploits user machine and thus allow remote code execution, see Can simply decompressing a JPEG image trigger an exploit?
In some situations you can use control of images to change the layout of the page, and faking parts of the page. It is not very powerful since I can't do anything dynamic, but it can be used in clever ways sometimes.
For example, if I can insert an
img tag in the search result page by searching for one, I could have an image with fake search results in it included. That way I could make it look like a search for "UFO" on the local news returns stories about the great alien landing of 2016.
If the vulnerability is inside an
a tag that performs an action, I could insert an image mimicing other parts of the page. That way, when the user clicks "OK" she is actually clicking on my image that contains a depiction of a fake "OK" button, but is actually part of the "Delete" link.
If I can create my own links with images in them, this gets even better...
As I said, not the most powerful hack in the world, but reason enough not to allow images where they are not needed.