Images with unknown content: Dangerous for a browser?
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.
开发者_C百科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.)
Security risks in image files crop up from time to time. Here's an example: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/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.
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.
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.
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.
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...
精彩评论