The following is just a rough stab at what you are looking for. The problem with handling the security in the "Parse_Form" routine is that security considerations will differ from application to application. Trying to embed the security directly into a form-parsing routine doesn't work. As security concerns change from application to application, the parsing routine would have to be adjusted. You either have multiple programs affected by the change or multiple copies of the form parsing routine.

Because I understand where you're heading with this, I'll make a suggestion. I do not recommend the following code, but perhaps it would let people new to CGI programming see how easy it is to use CGI.pm. Please note that the following code is untested.

sub Parse_Form {
    use CGI qw/:standard/;

    foreach my $key ( param() ) {
        my @vals = param( $key );
        if ( scalar @vals == 1 ) {
            $formdata{ $key } = $vals[0];
        } elsif ( ! @vals ) {
            $formdata{ $key } = undef;
        } else {
            # This should be adjusted as necessary.
            $formdata{ $key } = \@vals;
        }
    }
}
[download]

%formdata = map { $_, [ param( $_ ) ] } param;
[download]

The main problem there is how one gets a single value for the param "foo":

my $val = $formdata{ 'foo' }->[0];
[download]

I think too many programmers would balk at the awkward syntax.

Note how "multiple values" are handled in my original routine. Properly, multiple values that map to a single key should be represented in an array. Unfortunately, as you've discovered, many insist upon joining with a comma/space or with an ASCII zero (\0). How that final one is handled depends upon how to preserve current functionality of their programs.

Xxaxx asked:

Is this helping the weak stay weak?

Yes. Personally, I have strong objections to teaching people bad coding practices and then gradually bringing them up to speed. They wind up with many bad habits to unlearn. The reality, however, is that this is often the situation we have to deal with.

I will confess that I am unsure about how you're going about this, but that's probably because I haven't given it a lot of thought. If you must take this approach, I think the snippet above is probably a good start. If you want to more accurately duplicate the functionality of the original scripts, perhaps you should consider adding a standard HTML parsing module to look for SSIs or HTML comments. Then, you can strip them out (don't do a regex - they're trickier than you might think). However, this is going back to forcing your notion of security on them. That's not good practice, as mentioned above.

Good luck!

Cheers,
Ovid

Update: I forgot to mention some issues with your approach to security:

my $allowedCHARS = 'a-zA-Z0-9\!\"\#\$\%\&\'\(\)\*\+\,\-\.\/\:\;\<\=\>\
+?\@\[\\\]\^\_\`\{\|\}\~';
[download]

my $allowedCHARS = 'a-zA-Z0-9' . quotemeta( '!"#$%&\'()*+,-./:;<=>?@[\
+]^_`{|}~' );
[download]

Well, that clears it up and shows some serious problems. If you are going to hold their hand, hoping they don't get burnt, why even allow them to play with firecrackers? I see escapes, backticks, pipes, and dots, all of which are extremely common sources of security holes. Depending upon what is done with the rest of the characters (and on what OS they are running), there are still plenty of other issues here. I do like the fact that you state specifically what is allowed -- that's much better than stating what isn't allowed -- but it's still extremely permissive, depending upon what you want to do.

Security concerns simply vary too much from site to site. It is not possible to address them all in a form parsing routine. That's a limitation that you'll just have to accept and it is incumbent upon all of us to raise the awareness of these issues.

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