in reply to Upload file through perl-cgi not working
Even after you solve the "Insecure dependency" issue, your script will still have a major security issue.
Given these snippets from your code
... my $file = param("upfile"); my $upload_dir = "Y:\\Test\\user\\videos\\"; ... my $outfile = "$upload_dir".""; my ($safe_file_name) = $outfile =~ /([-\@:\/\\\w.]+)$/; if ($file =~ /swf/ || $file =~ /high/ || $file =~ /low/) { $outfile .= $file; ... # [ assign some stuff gleaned from $file to $safe_file_name - mlx ] ... open (my $fh, '>', $safe_file_name) or error_msg("Can't open $safe_file_name for writing: $!");
I could pass a value of '../../../../../../any/file/I/want.swf' to overwrite any swf file on the y: drive. I don't know enough about the NTFS file system to know if one could span filesystems - to c:/ for example.
"But that only allows you to exploit swf files" you may say. If I discover a directory named 'recipes_using_lowenbrau', I can now overwrite any and all files on your Y: drive (and perhaps others - see comment above about spanning filesystems) with the same technique, by passing a parameter for $file in the form '../../../joes_files/recipes_using_lowenbrau/../../../../now/I/own/all/files'.
You have to be very explicit in what you allow when sanitizing data from the web (or any other untrusted source). Note that I did not say "explicit in what you disallow". It is rarely (perhaps even "never") better to only use a disallow list to remove data, because someone else only has to find one thing that you missed (did you protect against alternate data streams, writing to device files (PRN, anyone?), or other ways of being a nuisance?). Your odds are much better if you list only what you allow, and call everything else invalid.
--MidLifeXis
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Upload file through perl-cgi not working
by Anonymous Monk on Aug 23, 2011 at 10:16 UTC | |
by becool321 (Initiate) on Sep 14, 2011 at 22:11 UTC |