You allow a possible malicious remote user to create and overwrite arbitary files on your webserver. I don't think that this is a pretty good idea. In fact, your webserver could easily be abused to serve malware.
Use a second input field to allow the user to specify an image name. Validate that input, restrict it to a set of safe characters. Abort the request if the name value is not valid. (E.g. use CGI::Carp and $name=~/^[A-Za-z0-9-_]$/ or die "Invalid name"
Make sure only images can be uploaded. Use one of the CPAN modules to validate the upload, don't rely on ANYTHING sent by the user, neither MIME type nor image file name. For example, Image::Size returns an error if the upload is not an image. This is also the place to restrict the image file size and the image dimensions. You don't want your users to upload gigabyte sized pr0n astronomical images, do you?
Abusing the filename on the client machine as filename on the server is also very inconvienient. What if I want to upload img0093.jpg as earth_and_moon_as_seen_from_the_surface_of_jupiter.jpeg? I would have to rename or copy the file locally(!) before uploading it, then I would have to rename the file back or delete the working copy. You could use some simple logic (either in Javascript on the client or in Perl on the server or both) to use the client's filename if no image name was entered.
Note that all these tests still don't solve the problem that any user can overwrite any file. If you don't want that, give each upload(!) a unique ID. UUIDs could help, or a column with an automatically generated ID in an RDBMS (use DBI). Use the ID to attach other attributes, like the image name, to the image. Use the ID as filename on the server, or store the image as BLOB in the RDBMS.
Alexander
In reply to Re: Scrubbing a local path in a file upload
by Anonymous Monk
in thread Scrubbing a local path in a file upload
by sier
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |