in reply to Re: CGI OO 'param' vs. hash
in thread CGI OO 'param' vs. hash

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.

Replies are listed 'Best First'.
Re: (Ovid) Re(2): CGI OO 'param' vs. hash
by legLess (Hermit) on Jul 10, 2001 at 00:06 UTC
    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]
        Thanks. I've read your course before (very helpful, BTW), but I must have stopped remembering the poison null byte when I saw this line, "However, the real fix is to avoid letting user data near the shell."

        This script will never, ever, let anyone pass a shell command (AFAIK; see next question). If this is the case, can I safely ignore said null byte, or should I strip it out just for fun? Also, see my reply above (directly below, the way this threading works) to tadman - I'm running with Taint on, and explicitly untainting every parameter I accept with a regex of "allowed" characters.

        If I do decide to pass shell commands, is your 1-liner $data =~ s/\x00//g; sufficient to guard against this problem?
        --
        man with no legs, inc.

[reply]

In Section Seekers of Perl Wisdom