Also, web developers should not care if the images are valid (and even valid images can contain JS!), at least not from security point of view. They should take care that they are served the right way (and not executed on the server), that they are small enough, that they have correct extension and mime type header - but that’s all.

I think IE is to blame, but yes, web developers must deal with it… :(

I don’t agree. If server sends header:

Content-Type: image/jpeg

then IE (as any other browser) should render the image as an image, not parse it as HTML!

This is a huge bug on IE side, and while the server can remedy things by carefully examining the images, that really should not be needed. This is clearly another IE bug.

http://jeremiahgrossman.blogspot.com/2006/12/i-know-if-youre-logged-in-anywhere.html

Interesting discussion indeed. Content checking is an ever coming up issue, and I think that browser vendors/creators should care. However it’s not on the file type recognition part but on the processing part where the stake lies. If a file has a .jpg ending it should be handled as JPEG and not be parsed as HTML (as in our above example), that’s all about sticking witzh standards.

It’s the same (many years now) with bad HTML code. Why should a browser interpret bad/non standard HTML code ? The result can be unexpected even not speaking about the security issue it implicates.

just my 5 cents,
pst

MySpace goes further and makes sure that it is a valid image and can be rendered. I’m not sure how it does it, but one of the possibilities I’ve thought of would be using something like the GD library to detect what type of picture it is then try and load it and if it fails then don’t move it to a web-accessible directory, and simply remove it.

So barring a vulnerability similar to the IE GIF one mentioned in this post I don’t think there are going to be any similar issues.

Adriaan, your English is good. I understand what you are talking about and I am on your side. Sure, browser can do some additional checks to verify that what it is receiving is what it says. Unfortunately, I can clearly see that this is not the case and it never be.

The problem here is that the Internet/Web is almost infinite. There are so many different file types out there that it takes a big afford just to put them into a database. Browsers, should take this a lot more seriously, sure, but is it feasible. I don’t know. Maybe they should be able to check for the most popular file types such as JPG, PNG, JS, CSS, GIF… etc. However, I can see how in certain situation this feature can break one or another company corporate application. So, from all browsers out there, only Firefox, Opera and a few others may implement this feature in the near future. I hope they do. IE will support all legacy stuff no matter what.

You are bringing some interesting points here. Let’s see if browser vendors will take your advice seriously.

I am following your blog for a little wile now, and I think it is really great that you point out so much issues.

In this post you say that these are not browser vulnerabilities, but server side problems. I don’t really get that.

Extensions don’t matter. So the browser looks to the content-type header what it is. When it says its html, does that mean that it should handle it as html? A image is most likely embedded in html or css. The browser should know by then (by tag or css) that it should handle it as image, and then ignore the header. It would be more clean if the browser takes the websites source as first priority how to interprent the file, instead of just accepting the header, imho. This would solve a lot of security issues.
Images which are not included by website source should then be handled as the content-type header says.

I hope you understand my english, and please correct me if I’m wrong.

Adriaan