Paperclip's solution still looks wrong to me. The require 'a' validation - of content type or filename. However, the content type comes from the browser - it's parsed from the headers with rack - and is completely under the attacker's control. It only helps you if you are going to serve back the file with the user-supplied mime type.
Homakov's attack relied on the file being served up with the mime type associated with the file extension, so the attacker's supplied mime type is only used to validate the file.
Even if you use the user's mime type to serve back the file, there's issues with the kind of validation paperclip does-they treat the file name and mime types as independent things. You validate to a white list of one, and separately to a white list of the other. Consider the use case of someone writing gmail. They want to allow a wide variety of file uploads; the paperclip validation does nothing because all mime types and extensions are allowed. However, it is combinations of things that are the problem; a thing uploaded as image/jpeg should have extensions of jpg or jpeg, not html; a text/html should have extension html not jpg.
Homakov's attack relied on the file being served up with the mime type associated with the file extension, so the attacker's supplied mime type is only used to validate the file.
Even if you use the user's mime type to serve back the file, there's issues with the kind of validation paperclip does-they treat the file name and mime types as independent things. You validate to a white list of one, and separately to a white list of the other. Consider the use case of someone writing gmail. They want to allow a wide variety of file uploads; the paperclip validation does nothing because all mime types and extensions are allowed. However, it is combinations of things that are the problem; a thing uploaded as image/jpeg should have extensions of jpg or jpeg, not html; a text/html should have extension html not jpg.