Today I will talk about Content-Type headers, and also why you should make good use of SOP ( Same-Origin-Policy ).

This is merely a thought experiment. I have done it only by looking in the HTTP traffic and browsing the webpage. No actual tampering happened.

The Oddity Within

I am a great fan of web2.0 stuffs. I was walking along a Hong Kong startup called FONCEPT, a startup where designers may upload their T-shirts and to sell them, and participate in various competitions. While appreciating the designs, I can’t help but noticed this odd page :

http://www.foncept.com/hk/designs/79

Notice what is wrong?

Look again at the image path.

http://uploads.foncept.com/Z8GvFzU2WQLd4X2isyFY-203

The file name has no file extension. Now, look at the Content-Type header.

x-amz-id-2: gfljmNR5XkOBLyPvLxYE+QBmuX6VRrbeU5seR+LI3WqmkIRXBcI1Rvxg8igSwyvn
x-amz-request-id: E458304A7189FC67
Date: Wed, 22 Apr 2009 15:24:43 GMT
x-amz-meta-s3fox-filesize: 54382
x-amz-meta-s3fox-modifiedtime: 1234846282000
Last-Modified: Mon, 02 Mar 2009 11:35:48 GMT
Etag: "b83173007445b85cf8bcef85036bfa72"
Content-Type: application/x-unknown-content-type
Content-Length: 54382
Server: AmazonS3

200 OK

The Content-Type header is used for hinting the browser whether or not to display the contents as HTML, or as Images, or as downloadable attachments, or even launch custom applications. However, the file extension might not be sufficient, as is this case. Images usually have these :

Content-Type: image/*

Content-Type: image/jpg

Content-Type: image/gif

Content-Type: image/png

An image having an application type is odd. Adding to the fact that this image is uploaded by user, this seems to be able to fool some browsers into display an image as active content, providing an opportunity for exploitation.

In testing with local environment, Internet Explorer 7, using FindMimeFromData, is susceptible to this attack and happily gets exploited.

The Attack Vector

FONCEPT operates by a user uploading an image, and then this image will be approved manually by backend operators. This image will then be resized appropriately and be put up on the website for display. The catch is, what kind of resizing mechanism it is using.

Assuming they are using some sort of well-formed library, the headers and attributes of the file should be maintained. We will craft a JPG that has comments header injected with javascript, and this will get executed.

Here is an evil image, and you can open it with a text editor and see the script :

<script>alert(1)</script>

Looks so evil!

The steps :

1. JPG with comment header injected with javascript code
2. JPG is uploaded to website for approval
3. JPG is approved and uploaded to the server
4. Access JPG through its stored URL through vulnerable browser ( Internet Explorer 7 ).
5. JPG is rendered as active content ( HTML ), and the script tag and javascript executes!

This is an example of an inappropriate MIME issue.

The Good News and the Fix

Thanks to the SOP, and thanks to the developers are separating the FONCEPT domains into various uploads.foncept.com and www.foncept.com and static.foncept.com , the attack is of much lesser value.

Vulnerable : uploads.foncept.com

Valuable contents and cookies : www.foncept.com

If uploads.foncept.com domain is not supposed to be render as active content (HTML), it should set the correct Content-Type header for the image files so as to avoid rendering the images as HTML.

The Conclusion

I randomly picked a few later uploaded images and they are appended with the right jpg extensions. If the new uploaded images still take filenames without extensions, and processed as is, then this is still susceptible to the exploit. I did not go into the effort to verify that.

I held a few assumptions in this thought experiment. However, this should be enough to demonstrate if the assumptions held true, will result in a genuine vulnerability by exploiting inappropriate MIME types.

—

References

MIME RFC list

Flirting with MIME types

The reason why compression works is that the plaintext contains redundancy. E.g. there are certain patterns in the text, character frequencies are not uniform, etc.

On the other hand, a good encryption algorithm should exhibit good diffusion and confusion. In short, it means that encrypted data should be indistinguishable from random noise. It is obvious that this property should hold regardless of the plaintext, otherwise the encryption algorithm is broken.

Therefore, compress-and-encrypt produces smaller output with no security compromise per se, but encrypt-and-compress is like feeding random noise (whose redundancy is greatly reduced) into the compression algorithm with no obvious security benefit.

In short, encrypt-and-compress poses no obvious security benefit. Moreover, given that a good compression algorithm should be like real noise, and should not contain pattern, it follows that there will be no obvious storage benefit, either.