On Wednesday 01 August 2001 10:20, Richard Lynch wrote:
> >> But I'm not
> >> using eval()
> >> directly on user entered data, and I can't see where it is possible.
> Yes, you are.
> pass1 is coming from the user, is it not?
> You are using eval() to decide if pass1 and pass2 are equal, are you not?
> You are therefore directly eval-ing user code.
> > "register_globals=off" in your php.ini and use $HTTP_*_VARS.
> Sigh. This does *NOT* provide *ANY* protection *WHATSOEVER*.
> The user can *STILL* POST malicious data, and you are *STILL* going to
> eval() it.
Aactually the eval()ed string would be:
eval('$a = $GLOBALS["pass1"]==$GLOBALS["pass2"]')
So there is no direct eval on the user data. I'm also using single quotes so
no special meaning chars would be expanded.
> I REPEAT:
> register_globals off and HTTP_xxx_VARS being more "secure" is a gross
> It will only trip the dumbest of the dumb trying to crack your site --
> We're talking lower than script-kiddies. Think Joe Sixpack and Betsy Buick
> here. Normal users who have noticed those funky things in URLs and decided
> to play around with them on FORMs to see what they can do.
> A *REAL* script-kiddie (did I just say that?) would take your HTML FORM,
> edit it in NotePad, and then POST their malicious data and your
> HTTP_POST_VARS have *bad* things in it.
Yes and I agree with you (see the answer to Yauso). The only concern is GPC
vars overwriting script vars, and as mentioned I unset those var before
assigning them a value or before using session register to get their values.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]