Re: Form, Input, Taint related

Thanks for the replies!

Well instead of CGI.pm, as of now I'm using this example I got from a web site.

sub startup {

$query=$ENV{'QUERY_STRING'};
    if ($query) { @pairs=split(/&/,$query); }
    else {
        read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
        @pairs = split(/&/, $buffer);
    }    
    foreach $pair (@pairs) {
        $something_in=1;
        ($name, $value) = split(/=/, $pair);
        $value =~ tr/+/ /;
        $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
        $name =~ tr/+/ /;
        $name =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
        if ($INPUT{$name}) { $INPUT{$name} = $INPUT{$name}.",".$value;
+ }
        else { $INPUT{$name} = $value; }
}
}



#then when I want to retrieve a value for the input field called "name
+", then I will use:

&startup;
print "$INPUT{'name'}
[download]

This is the other alternative I was talking about. Is this as safe as using CGI.pm Input method?

Thanks!

Comment on Re: Form, Input, Taint related Download Code

Replies are listed 'Best First'.
Re^2: Form, Input, Taint related by merlyn (Sage) on Apr 15, 2005 at 20:48 UTC
Uh, no. This fails to handle modern form encodings, and select-multiple fields in any useful way. And probably a few dozen other shortcomings. Use CGI.pm, please. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^2: Form, Input, Taint related by jhourcle (Prior) on Apr 15, 2005 at 22:03 UTC
The biggest issue that I see is that you're trusting the CONTENT_LENGTH header, and not placing any restriction, to make sure that someone doesn't claim it to be 50GB or some other excessive number. It's possible that because the values weren't being tested for taint, that they might cause other problems, but I don't know how you're using the data. If you're just printing to a log (that you're viewing with only a text editor), or report, or whatever, you might be just fine with the rest of it. If you use input as the basis for something that results in a filename, system call, database call, e-mail, or anything else that can be abused, you might want to rethink how values are being parsed. Although there's a bit of overhead from CGI.pm, because of all of the HTML generation bits, that you won't be using, it can provide for more robust input handling, and the ability to fix things in one spot, rather than spread across every file that handles CGI input. Make sure you look at the notes in CGI::Safe, though.	[reply]