New meeting place

Shay Harding mekla at
Thu Sep 2 22:40:14 CDT 1999

>\_ I'm very interested in this thread.  However, I don't have
>\_ the time to become 'one' with the manual, David. ;-)
>\_ What exactly is the 'major security risk'?  Can someone
>\_ explain it in basic terms?
>Depends, among other things, if you like having your variables
>Suppose you have a variable 
>$a = 1;
>and it actually does something important.  Now, further suppose you go
>put the CGI params in your namespace.  $a could be clobbered.  But,
>you say, "I don't use 'a' as a CGI variable."  And that may in fact be
>true.  But that doesn't support someone else from hacking your HTML
>and *adding* the variable to the list.  So, kiss $a good bye.  Now, if
>you have something that actually gets eval'd or something like
>that...presto! arbitrary code running on your server.  Everyone who's
>now nervous, please stand up.
>There are probably other issues, but that's a good one to get your
>attention.  :-)

Well, consider that with a form, you are not going to use variables you did
not create. So if someone added form fields, the chance of them hitting a
variable you use is slim, although it does exist. Importing into a 'safe
zone' (different namespace) is the safer of the two. For the most part if
you scope your variables using 'my', you can avoid most of this problem.
Scope your form variables globally, and all other variables lexically so
even if someone puts extra stuff in your form, they shouldn't affect
variables of the same name within subs, ifs, whiles, etc.

So if you had a form with fields (field1, field2) and someone added

use CGI;
$cgi = new CGI;

for ($cgi->param()){
    ${$_} = $cgi->param($_);


sub something(){
    my $field3 = 15;
    my $result = $field1 + $field2 * $field3;

OK, now the added 'field3' through the form just sits there and is
harmless. I guess it really depends on how the code is structured and to
what extent it actually issues system commands and such.


More information about the Phoenix-pm mailing list