Of course, the canonical reply would be to use
CGI.pm which handles all of this nasty
stuff quite well and comes with about every Perl distribution I know.
CGI.pm also takes care of the tempfile creation, removal and
I guess that there are no backdoors or exploits in CGI.pm itself.
There are at least two things wrong with the code :
First, no error checking. Opening a file should
always be done like this (in my holy opinion) :
local *FILE;
open( FILE, "> $file" ) or die "Couldn't create '$file' : $!\n";
...
close( FILE );
Of course, it's not always adequate to die(), but
at least a warn is in place and for tools
or CGI stuff, a die isn't bad, as the stuff
will show up in the error log of the server.
The second thing is, that the file will be clobbered
under Win32, as it is used for binary data and no
binmode() is used on the
file handle. This will not affect writing ASCII data
in any way and it will also have no effect under
UNIX platforms.
Looking further through the code, I see that
$form_data is printed to STDOUT instead
of (as it maybe should be ?) to FILE. Maybe that's
already the error... Also, because there won't be
more (or less) bytes available on STDIN than
$ENV{'CONTENT_LENGTH'} indicates, reading
from STDIN could simply be done by using the
following code :
{
local $/ = "";
$form_data = <>;
};
# $form_data now contains the submitted stuff
But I would really use CGI.pm for such stuff like
file submission !
|