[thelist] PHP sessions & security, etc

Carl J Meyer cjmeyer at npcc.net
Wed Dec 11 19:49:01 CST 2002

On Wed, 2002-12-11 at 16:56, Tom Dell'Aringa wrote:
> Is there any quantifiable evidence to the fact that these
> 'superglobals' are unsafe? It seems strange that an open source
> community like php would offer such unsafe functionality. I'm not
> saying its not, but I'd like to see some hard facts.
> >From what I have read (which isn't probably much compared to most of
> you) the global variables were a great thing and are used everywhere.
> What kind of security holes does it make? Are these globals somehow
> accessible to an outside source? How would you pull a variable like
> that out?


Good questions.  You can read the official PHP commentary on this at

Here are my comments.

First, a terminology clarification.  "Superglobals" is generally used to
refer to the arrays $_POST, $_GET, $_COOKIE, $_SERVER, etc which are the
recommended way to access "external" data in PHP (ie a POST method form
variable named 'name', when submitted to a PHP page, is available via

"register_globals" is the php.ini setting which determines whether data
from those "superglobal" arrays is also automatically converted into
global variables - ie, if register_globals is on, then $_POST['name'] is
also available as simply $name.

I believe your use of "superglobals" is a bit different, you're using it
instead to refer to the global variable created by "register_globals=on"
(ie $name).  I will use the standard terminology.

Why is unsafe functionality (such as register_globals=on) offered?
Because PHP has evolved over the past few years from a small set of C
hacks that Rasmus Lerdorf wrote to make managing his personal site
easier, into a mature full-fledged web scripting language.  Along the
way many things have changed and been improved.  register_globals is one
thing that was part of the original package that is now in the process
of being dropped because it is a bad idea.  It hasn't been dropped
entirely because there's lots of old code out there that needs it, so
for backward compatibility reasons the option is still there to use it.

I'm not sure where you read that register_globals=on is "used
everywhere."  Lots of old code (ie code written for PHP3 and earlier)
uses it.  Lots of code written by PHP newbies uses it, because at first
it seems easier.  But no experienced PHP developer would use
register_globals in starting a new project today.  As the PHP site
clearly states, register_globals=off is now the default and preferred
setting, and everyone is strongly encouraged to write code that assumes

The PHP manual page I referred you to above has a fine explanation of
the security issues.  The concern is not that someone can "pull these
variables out" somehow and gain access to the data in them, it is that
anyone who can access your script via the web can add arbitrary global
variables into your script as easily as sticking "?var=val" onto the end
of the URL.  One mistake in your code (such as unwary use of an
uninitialized variable) can potentially lead to anyone being able to
execute arbitrary code as the web user on your server.  This is a
serious issue, and if you read BugTraq you'll see that PHP sites and
software packages are regularly discovered to be vulnerable to this type
of 'variable-poisoning' attack.

An equally-important reason to use the superglobal arrays is that it
leads to better, more readable and maintainable code.  If you just
suddenly access a variable called $name in your script, who knows where
that variable came from?  Is it uninitialized?  Did it get set from a
cookie?  Is it from POST data?  Is it from the GET data?  The fact is it
could be any one of those, your original intentions notwithstanding, and
reading your own code a year down the road you may have no idea what was

On the other hand, if you use the superglobal arrays, you always know
exactly where your data is coming from, and there is no confusion in
reading the code.

The last good reason to use the superglobal arrays is if you're writing
code that you might at any point want to package up and offer to other
users.  The fact is that most PHP servers nowadays set
register_globals=off, so if your code depends on it being on, you're
just out of luck.  Whereas if you follow the standard and use the
superglobals, your code will work on any PHP 4 server, regardless of the
register_globals setting.

Hope that helps explain the situation,


More information about the thelist mailing list