[dev] Fwd: Re: [PHP-DEV] [PATCH] Fix for bug #31440 (GLOBALS can be by G/P/C when register_globals=On)

[Chuck Hagenbuch]

We should probably do some checking to see if we're vulnerable to 
things like this...

----- Forwarded message from rasmus at lerdorf.com -----
    Date: Wed, 16 Feb 2005 08:46:57 -0800
    From: Rasmus Lerdorf <rasmus at lerdorf.com>
Reply-To: Rasmus Lerdorf <rasmus at lerdorf.com>
Subject: Re: [PHP-DEV] [PATCH] Fix for bug #31440 (GLOBALS can be by 
G/P/C when register_globals=On)
      To: Stanislav Malyshev <stas at zend.com>
      Cc: Andi Gutmans <andi at zend.com>, internals at lists.php.net

Stanislav Malyshev wrote:
> AG>>>Seems like a bad excuse.  Being able to destroy a superglobal 
> array like AG>>>that is clearly a bug that should be fixed.
>
> IMO there should be no possibility to destroy GLOBALS with ?GLOBALS=foo,
> but there should be possibility to write GLOBALS with ?GLOBALS[foo]=bar -
> why not, if we allow accessing globals anyway? I didn't check how 
> hard it should be to separate these - if it's hard then restricting 
> access to GLOBALS would be good.

Yup, I agree.  GLOBALS[foo]=bar is perfectly fine since that doesn't 
destroy the array and prevent a $foo global locally defined from 
overriding it.  The problem with the current situation is code like 
this:

<?php
     $password_checked = true;
     ...
     if($GLOBALS['password_checked']) do_something;
?>

This application can be hacked by simply sending it a ?GLOBALS=foo in the URL.

-Rasmus

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


----- End forwarded message -----


-chuck

-- 
"But she goes not abroad in search of monsters to destroy." - John 
Quincy Adams