9

As it is known, older versions of MSIE (before 8) have a nasty habit of treating images as HTML if they "look like" HTML, which can lead to nasty vulnerabilities for sites that allow people to upload images. Even though it is fixed in IE8, there's still a lot of IE7 and before around, so this needs to be addressed. So the question is, how it is best to address it, given:

  1. PHP site with file uploads
  2. Not recoding images (i.e. stuff like ImageMagick can't be used)
  3. Direct access to images should be allowed
  4. We can not prohibit people from using "wrong" extension

Would checking first 256 bytes for something like <(html|body|img|script|head)> be enough? Any better ways to do it?

Improve this question
2

2 Answers 2

Reset to default
5

http://www.adambarth.com/papers/2009/barth-caballero-song.pdf is a excellent overview reference of the problem. It is not only for images, also for txt files and others...

Improve this answer
0
4

No, checking the first 256 (or any given number) bytes is definitely not enough.

Even if you were to be able to verify (btw you'd need to check approx. 4K bytes...) that there is no HTML there (ignoring the ease of obfuscating that HTML via encodings etc), HTML is not the only malicious possibility that might be hiding within your image (I assume it's images that are being uploaded?)

For example, see this question on corrupted image vulnerablity - not only buffer overflows, but as my answer stated the possiblity of GIFAR (and similar formats), which is essentially both a completely valid GIF, but also a valid and executable JAR file. This is because not all file formats have their headers at the beginning of the file.
So, checking the beginning is explicitly NOT the way to go.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .