You can do this with:
extract($_REQUEST, EXTR_SKIP)
However, you are making some invalid assumptions here. Script variables
get initialized after the request variables are automatically imported, so
this overwrite switch could not be a high-level php.ini switch. You can
do it with a user-space level function like extract() because in this case
you can choose when to pull the request variables into your script.
I actually prefer doing the opposite. Something like:
<?
$name = $age = $gender = true;
extract($_REQUEST, EXTR_IF_EXISTS);
?>
This fetches only the variables I have defined into the global symbol
table.
-Rasmus
On Fri, 3 May 2002, Luis Ferro wrote:
> That would be easy to solve by just adding a non_overwrite flag to the
> vars and thrus forbid the vars from get/post to override vars in the
> varspace that come from programming and not from get/post...
>
> One would keep the global vars but would also have the security of the
> existing/declared vars be protected from overwrite (only get/post vars
> would be allowed to be overwriten between page initializations)...
>
> Cheers,
> Luis Ferro
>
> Matt Parlane wrote:
>
> >Posting the variables might solve the problem in this case, but remember
> >that this is just an example, and I'm sure any creative mind could come up
> >with a whole heap of ways you could exploit something like this.
> >
> >On the other hand though, you don't have to use it. If you are confident
> >you can write an application without using the new superglobal arrays (and
> >it is conceivably possible), you can just turn register_globals on. It's
> >just a choice which was made by the PHP developers (rightly so I believe).
> >
> >Matt
> >
> >"Then" <[EMAIL PROTECTED]> wrote in message
> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >
> >
> >>Hi
> >>
> >>At the cost of sounding dense...wouldn't POSTing the variables solve the
> >>problem. Then the user would not see them in the URL.
> >>
> >>
> >>[EMAIL PROTECTED] (Matt Parlane) wrote in
> >>[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
> >>
> >>
> >>
> >>>Hi...
> >>>
> >>>The problem comes when you are mixing variables recieved from the HTTP
> >>>request, and your own user variables. Consider the following code:
> >>>
> >>>function authenticate_user(){
> >>> if($password == 'secret'){
> >>> $authenticated = 'yes';
> >>> }
> >>> return $authenticated;
> >>>}
> >>>
> >>>If someone passes the variable authenticated=yes in the url request
> >>>string, the user will be authenticated no matter whether their password
> >>>matches or not. This is obviously a simplified example, and I'd hope
> >>>that no programmer would ever do this, but things like have been known
> >>>to happen, and there have already been exploits for it.
> >>>
> >>>The logic behind the change is that it is really not much extra work to
> >>>type $_GET['something'] than just $something, and it is infinitely more
> >>>secure - so you should write your scripts using the $_REQUEST variables
> >>>whenever possible.
> >>>
> >>>Hope that helps...
> >>>
> >>>Matt
> >>>
> >>>"Then" <[EMAIL PROTECTED]> wrote in message
> >>>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >>>
> >>>
> >>>>Hi All
> >>>>
> >>>>I am a PHP newbie. I don't understand why global variables are turned
> >>>>off
> >>>>
> >>>>
> >>>by
> >>>
> >>>
> >>>>default in PHP4.2.0... something to do with security. Could some one
> >>>>
> >>>>
> >>>please
> >>>
> >>>
> >>>>help me understand how it's a security issue. Thanks
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>--
> >>Lots of Luck
> >>theN
> >>[EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> >
> >
>
>
>
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
