in reply to CGI OO 'param' vs. hash

I prefer passing the $q query object in its entirety for a few reasons. In particular, it is always handy to be able to get "other" information from it without having to pass this extra stuff explicitly. For example, if you had one function that not only needed the parameters but the REMOTE_HOST info, you would have to extract this and pass it explicitly.

Better to just toss the $q variable into the function and extract params like you would.

Don't forget, though, that since you are extracting the parameters directly from the CGI object, they are tainted until decontaminated by your program. This decontamination can be done by a simple module which is used throughout your program, or by sub-classing CGI to build in this functionality. Consider: 
# Regular CGI
my $quantity = $q->param('quantity');            # Tainted

# "Fancy" CGI of your own construction
my $quantity = $q->SafeNumberParam('quantity');  # De-tainted

[download]
Where your SafeNumberParam function might look like: 
sub SafeNumberParam
{
    my ($self)  = shift;
    my ($param) = @_;

    my ($number) = $self->param($param) =~ /^(\d+)/;

    return $number;
}

[download]

Replies are listed 'Best First'.
(Ovid) Re(2): CGI OO 'param' vs. hash
by Ovid (Cardinal) on Jul 09, 2001 at 23:16 UTC

    Another good reason to subclass CGI.pm would be to get rid of that Vars() method and replace it with one that uses data structures properly.

    sub Vars {
    my $self = shift;
    my %formdata;
    foreach my $name ( $self->param ) {
        my @values = $self->param( $name );
        $formdata{ $name } = scalar @values == 1 ? $values[0] :
                                                  \@values    ;
    }
    return \%formdata;
}

    [download]

    Of course, that's quick-n-dirty and I haven't tested it. It has the nice effect of getting rid of all of those nasty ASCII zeroes in the original Vars function, thus stopping a nasty potential security hole.

    Cheers,
    Ovid

    Vote for paco!

    Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
[d/l]
      Quoth Ovid:
      Of course, that's quick-n-dirty and I haven't tested it. It has the nice effect of getting rid of all of those nasty ASCII zeroes in the original Vars function, thus stopping a nasty potential security hole.
      Can you elaborate, or shoot me a URL? I have no idea what you mean.
      --
      man with no legs, inc.
[reply]

        As I recall, the original CGI::Vars function will separate values with an ASCII zero. By allowing ASCII zeroes into the data, you have two problems.

        1. Since we seperate data with an ASCII zero, what happens if we ever need to embed one? You'll not likely to run into one, but the one time you do...
        2. You run the risk of a security problem called "The Poison Null Byte". Go to this overview of CGI security and search for "Poison". That should take you right to a description of the problem.

        Cheers,
        Ovid

        Vote for paco!

        Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
Re: Re: CGI OO 'param' vs. hash
by legLess (Hermit) on Jul 10, 2001 at 00:11 UTC
    Thanks tadman, that's a nice WTDI. I do validate every CGI param coming from the user before I stick it into the database. That way I can warn them and give them another shot at getting it right. 
    if ($prm{'name'} =~ s/[^\w \-]//g) {
    $warning .= '<LI>Illegal characters were removed from your Login N
+ame. Only letters, numbers, spaces, underscores and dashes are allowe
+d.';
    }

    [download]

    Your way is more elegant though. Gives me something to think about.
    --
    man with no legs, inc.

[reply]
[d/l]

In Section Seekers of Perl Wisdom