security issues for allowing images to be uploaded to the server

[jonnyfolk]

Before posting this question I started by searching the CPAN for a module through which one could upload an image file to a server, and would refuse anything that was 'dodgy'.

I didn't find what I wanted and so I wondered if fellow monks had experience of allowing this (those who would upload are relatively trustworthy but I would wish to guard against a rogue element). I would certainly check the suffix of the file but I would be grateful to know of any internal checks one could make on the file to improve security.

All help and advice gratefully received.

[rob_au]

There a number of security issues which can be raised by allowing files to be uploaded to a web server, but the majority of these security issues relate to how the files are used after being uploaded, rather than the action of uploading the file itself. Some of these issues can be addressed through the careful vetting and validation of the uploaded file prior to use or employ in other process or business applications. These issues have been raised for discussion on PerlMonks in previous posts here, here, here and here.

It was with these issues in mind that I wrote the CGI::Upload module - This module incorporates methods for validating the supplied file name and file content, the latter of which is particularly important as it is relatively trivial for a malicious user to rename a file to incorporate an 'allowed' file extension prior to upload. Further to this, I would recommend defining the $CGI::POST_MAX as recommended by the CGI::Safe module by Ovid within your upload script to set a ceiling on the size of uploaded files.

 

perl -le 'print+unpack("N",pack("B32","00000000000000000000001001010110"))'

[crenz]

I'd recommend setting a maximum upload limit. Apart from that, it depends on what you mean with "dodgy". If you just want to make sure the file is a valid image file, you could try to open it with Imager or Image::Magick and delete the file if it doesn't open okay.

[grantm]

Depending on your application, you might get away with something as simple as a maximum filesize. That would stop your server being used for hosting warez (if not pr0n).

[jonnyfolk]

Thanks for replying. Do you have experience on what should be a maximum file size?

[grantm]

Off the top of my head, I'd say 200K would be pretty large for an image but fairly small for an MP3 file (so people would probably not want to bother using your server to store MP3s). It really does depend on your application though.

[bart]

You can check the mime type associated with the uploaded file, before accepting it, i.e. moving it from its temporary location where it got uploaded, to its final destination.. It's the browser used for the upload that sets it, so I suppose that in general it is smart enough to recognize the platfrom-specific quirks. See the docs for CGI.pm to find out how to get at it:

When a file is uploaded the browser usually sends along some information along with it in the format of headers. The information usually includes the MIME content type. Future browsers may send other information as well (such as modification date and size). To retrieve this information, call uploadInfo().

Alternatively, when this is uploaded to a Unix-like system, you could use the file command line utility to check out what you got. It's really worth playing with a little.

[archen]

Filenames are something to consider. For instance, allowing something called ../index.html is probably something you don't want. Checking mime types and file extensions is one thing, but consider generating a new file name in the script instead of trusting user input might help security if the file name doesn't matter.

[jonnyfolk]

The way this will be set up, there will be a fixed path to the image file, and the new image will be named by the script, probably by timestamp, so I don't think there is an issue (though I always stand ready to be corrected(:) Thanks, glad you mentioned it ...

[adamcrussell]

Hope this helps: Make use of the "magic number" of a file to determine its type. Most *nix systems will have a file called /etc/magic (look at the manpage for the file command for your specific system) which contains the "magic numbers" for many many different filetypes. All the mainstream image formats support this. So, by looking at the very first few bits of the file you can tell if it is an image file or not by way of a comparison with entries in /etc/magic. Now, keep in mind that this allows you determine what a file is calling itself. I am sure there are ways a skilled evil do-er might be able to circumvent a simple magic number test.

[markjugg]

I was just planning to post something about the new beta of Data::FormValidator I'd like folks to review, and this question is a great segue into that. :)

One of the new additions I'd like people to test for me is a new module to help you validate file uploads, especially images.

• Download the beta (If that breaks, it may be because a newer version has been released)
• The documentation
• A example application (doesn't use file uploads)

Currently the module can validate your file based on file size, image dimensions, and file format (based on mime type and file extension). A patch to support magic numbers would be cool.

-mark

[submersible_toaster]

Not sure if you're already on the path but File::MMagic is a nice perl implementation for getting MIME type by magic!


I can't believe it's not psellchecked

[markjugg]

Thanks for the pointer. I wasn't aware of File::MMagic, and it seems like a better solution than trusting either the mime type or extension that is sent with the file. Maybe I'll try "Magic" and if that fails, and if that can't be found, try the mime-type, and if we can't try that, check the extension.

Can anyone vouch for the accuracy of File::MMagic for usual web upload cases?

-mark