views:

75

answers:

5

Let's say I allow users to link to any images they like. The link would be checked for syntactical correctness, escaping etc., and then inserted in an <img src="..."/> tag.

Are there any known security vulnerabilities, e.g. by someone linking to "evil.example.com/evil.jpg", and evil.jpg contains some code that will be executed due to a browser bug or something like that?

(Let's ignore CSRF attacks - it must suffice that I will only allow URLs with typical image file suffixes.)

+3  A: 

Security risks in image files crop up from time to time. Here's an example: http://articles.techrepublic.com.com/5100-22_11-5388621.html?tag=nl.e019. It's an old article, so obviously these things have been rolling around for a while.

While it's impossible to say for sure that something is always safe/never safe, so far it sounds like the risks have been relatively low, and are patched by the image viewer manufacturers pretty quickly. IMO the best test is how often you hear about actual problems occurring. This threat vector has been a known possibility for years, but hasn't really become widespread. Given the extent to which people link images in public forums, I'd expect it to become a big problem pretty quickly, if it was a realistic sort of attack.

Curtis
+1  A: 

There was a JPEG buffer overrun some time ago. Also, you have to account for images who actually contain code, so that you don't execute the code.

Sjoerd
+1  A: 

Yes, this could be a problem. There is quite a few exploits known that work by using vulnerabilities in the image rendering code of the browser or the OS. Including remote execution vulnerabilities. It might not be the easiest flaw to exploit, but it is definitly a concern.

An example of such a vulnerability : http://www.securityfocus.com/bid/14282/discuss (but you could find tons of other vulnerabilities of the same type).

I think I remember such a problem with a high visibility site having exactly this kind of vulnerability exploited. An advertisement image was displayed from some third party ad provider, and the image had not been checked. 1000's of users compromised ... Cant find the story anymore ... sorry.

Guillaume
A: 

UPDATE: Proofed wrong!

You also have to consider, that cookies (that means sessionIDs) are also sent to the server where the image is located. So another server gets your sessionID. If the image actually contains PHP-Code it could steal the sessionID:

For example you include:

<img src="http://example.com/somepic.jpg alt="" />

On the server of http://example.com there's a .htaccess-file saying the following:

RewriteRule ^somepic\.jpg$ evilscript.php

then the pic actually is a php-file, generating the image, but also do some evil stuff, like session-stealing or whatever...

faileN
Wouldn't my cookie only be sent to my domain?
Chris Lercher
Cookies and their values are sent via the http-protocoll, as you know. So the user sends a request to your page. Your site has to load some stuff, like js-files, css-files and images of course. For each resource a new request will be sent to the location, where this resource is located. You can see that when using firebug (look at the network-tab). There you see, that all Requests (which are containing your cookie-data as well) are sent to every resource. So the cookie data will be sent to the foreign image, because it was called from your site. To proof this, I could make a screenshot 4 you
faileN
You really want the https only option for cookies with https.
Tom Hawtin - tackline
@faileN: If there's any chance, that something like that can happen, I want to know about it. Yes, if you can provide the screenshot of your scenario, that would be great!
Chris Lercher
I just re-checked it and it seems that I was wrong. The cookies (at least the session-cookie) won't be sent to the other server. So ignore my explanation-post. But I was pretty sure, that this is a common technique with stealing sessions on ebay, amazon, etc.
faileN
@faileN: Thanks for checking! What you probably had in mind, are third-party cookies. They will be sent with the image request (if they're from a domain that sets cookies), but don't contain the info from my own cookies.
Chris Lercher
+1  A: 

So there's potential buffer overflows with handling untrusted data, however you get to it. Also if you insert untrusted data in the form of URLs into your page then there is a risk of XSS flaws. However, I guess you want to know why browsers flag it as a problem:

Off the top of my head:

  • I believe referrer information is still sent in this case. Even if you don't ever and wont ever use URL rewriting for sessions, you are still exposing information that was previously confidential. chris_l: True, I just did a quick test - the browser (FF 3.5) sends the Referer header.

  • You cannot be sure that the image data returned will not be misleading. Wrong text on buttons, for instance. Or in bigger images, spoofing instructions, say.

  • Image size may change layout. Image loading could even be delayed to move page at a critical time. chris_l: Good point! I should always set width and height (could be determined by the server when the user posts the image - would work as long as the image doesn't change... better ideas?)

  • Images can be used for AJAX-like functionality. chris_l: Please expand on this point - how does that work?

  • Browsers will flag an issue with your site, hiding other problems and conditioning users to accept slack security practices. chris_l: That's definitely an important problem, when the site uses HTTPS.

Tom Hawtin - tackline
@TomHawtin: I inserted a few comments in the answer, I hope you don't mind. Please expand on the point "Images can be used for AJAX-like functionality"! Thanks.
Chris Lercher