views:

341

answers:

1

I built a photo gallery which uses Paperclip and validates the content-type using validates_attachment_content_type.

The application runs on a shared host with Passenger.

Is it possible to bypass the validation and run malicious scripts from the public/pictures directory? If so, is there anything that I can do to avoid evil scripts from running or from being uploaded?

+2  A: 

Is it possible to bypass the validation and run malicious scripts from the public/pictures directory?

Yes. You can have a perfectly valid renderable image file that also contains HTML with script injection. Thanks for the bogus content-sniffing, IE, you have ruined everything.

See http://webblaze.cs.berkeley.edu/2009/content-sniffing/ for a summary.

If so, is there anything that I can do to avoid evil scripts from running or from being uploaded?

Not really. In theory you can check the first 256 bytes for HTML tags, but then you have to know the exact details of what browsers content-sniff for, and keeping that comprehensive and up-to-date is a non-starter.

If you are processing the images and re-saving them yourself that can protect you. Otherwise, do one or both of:

  • only serve user-uploaded files from a different hostname, so they don't have access to the cookie/auth details that would allow an injected script to XSS into your site. (but look out for non-XSS attacks like general JavaScript/plugin exploits)

  • serve user-uploaded files through a server-side script that includes the 'Content-Disposition: attachment' header, so browsers don't attempt to view the page inline. (but look out of old versions of Flash ignoring it for Flash files) This approach also means you don't have to store files on your server filesystem under the filename the user submits, which saves you some heavy and difficult-to-get-right filename validation work.

bobince
If you are resizing images (via ImageMagick) will the HTML + script "survive" the change?
Mike Buckbee
No, any bytes in the compressed stream would be recompressed and lost. Any other structures (eg. a comment field) should noramlly be discarded when making a smaller version of an image. In theory if you knew the exact resizing settings in advance you might be able to craft an image that, when resized and compressed, would end up with HTML-like bytes in the resulting stream, but that would be a very very difficult attack, probably practically quite infeasible. I've certainly never heard of it happening.
bobince