Re: Re: Trying to avoid code exploits..

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 > exaggeration. > > 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. -- Kriheli Meir