On Sat, May 13, 2006 5:11 pm, Nick Wilson wrote: > are there any security concerns with uploaded images? YES!!! > My thought is that it wouldnt be too hard to have some kind of script > masquerade as a gif file, and perhaps cause damage. > > I cant find anyway to check a file really is a gif/png/jpg http://php.net/getimagesize will tell you if it kinda sorta at least LOOKS like a vaild image, and what kind it looks like. While this cannot GUARANTEE that it's a valid GIF, you at least know that the first N bytes *LOOK* like a valid GIF. So they'd have to upload a malicious script with a GIF header, such that the GIF header didn't cause the bad script to malfunction. This is an order of magnitude more difficult (and requires more thinking) than just uploading any old binary file and surfing to it. WARNING: I've had trouble with getimagesize and/or browser non-support on: 1. some EXIF data in some JPEGs. 2. progressive JPEGs 3. Stupid AOL "Save" that uses .jpeg for AOL images, which are really just GIF or JPEG [whichever is smaller], wrapped in an AOL header). 4. Interlaced images (GIF?) I don't remember which one of these four was the one that getimagesize didn't like... But it DOES constrain at least one kind of image that users might be trying to upload -- and it maybe got fixed anyway, for all I know. > (i assume > the > mimetype available in $_FILES could be spoofed). YES! Plus, all the browsers return DIFFERENT mime-types for the same kind of file anyway, so the whole thing is kind of bogus/pointless anyway. > I'd welcome any thoughts in general on this, but specifically if > anyone > has experience/knowledge in this area and can point me in the right > direction. How about this? Don't even PUT the image file in your web tree! Write a little wrapper PHP script that does http://php.net/readfile (or a fopen/fread/echo on a buffer for larger images) on the files that you store in your NON-WEB-TREE directory. Or, for that matter, load the images in through http://php.net/gd and then you will detect a bogus image before sending it out. EG: ~/your_home_directory /public_html /script_to_display_images.php /private_space_not_visible_through_http /images /whatever.gif So now, the only people that can possibly get your "images" to be executed either: A) already have a login on the box, and don't need them B) Found some *other* hole that lets them execute arbitrary files on your server, and your uploaded images aren't the likely target anymore. Obviously, these choices have performance penalties. Running every image through PHP to check it on output is maybe not something you can do on a high-volume server. But for low-, or even medium-volume servers, it can sure make for a simple way to pretty much guarantee that the uploaded images are not a big chink in your armor. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
