PHP 4.0 Bug #9020 Updated: Registered variables can be set in URL on first run
| From: | paul_kroll at hotmail dot com | Date: | Tue, 20 Feb 2001 19:16:23 +0000 |
| Subject: | PHP 4.0 Bug #9020 Updated: Registered variables can be set in URL on first run | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-47085@lists.php.net to get a copy of this message | ||
ID: 9020
User Update by: paul_kroll@hotmail.com
Status: Closed
Bug Type: *Session related
Description: Registered variables can be set in URL on first run
The negative effects of register globals aren't in question here: this is a behavior that is
going to lead to exploits. If the register_globals ALWAYS allowed form variables to override the
session variables, I'd see it as reasonable to tell PHP coders to turn that feature off as
it's just not safe. But this situation only happens On First Try, before a session is created.
Because of that, many, many programmers are going to assume using session vars is safe and
they'll be NEARLY correct.
It's fine to say that register_globals should be off, but that doesn't change the bug: PHP
sessions should replace global form variables not just after the session is created, but on first
try as well. Or they should always let form variables override session variables. The mix of
behaviors is what's problematic.
Previous Comments:
---------------------------------------------------------------------------
[2001-02-20 14:12:26] paul_kroll@hotmail.com
The negative effects of register globals aren't in question here: this is a behavior that is
going to lead to exploits. If the register_globals ALWAYS allowed form variables to override the
session variables, I'd see it as reasonable to tell PHP coders to turn that feature off as
it's just not safe. But this situation only happens On First Try, before a session is created.
Because of that, many, many programmers are going to assume using session vars is safe and
they'll be NEARLY correct.
It's fine to say that register_globals should be off, but that doesn't change the bug: PHP
sessions should replace global form variables not just after the session is created, but on first
try as well. Or they should always let form variables override session variables. The mix of
behaviors is what's problematic.
---------------------------------------------------------------------------
[2001-02-20 13:57:52] sas@php.net
The negative effects of the easy accessibility of form variables is well-known; if you want to avoid
them, please disable register_globals and use $HTTP_SESSION_VARS exclusively.
---------------------------------------------------------------------------
[2001-01-31 00:51:35] paul_kroll@hotmail.com
Ref: think this is what the person was getting at in bug 8184.
---------------------------------------------------------------------------
[2001-01-31 00:35:58] paul_kroll@hotmail.com
One of the last comments on http://www.php.net/manual/en/ref.session.php
by bpeikes@hotmail.com is dead-on: if sessions.auto_start is 0/off, and session globals are on, a
session variable can be set from the URL if it's done before the first-hit on the server. This
is easier to see if you turn off cookies in your browser (otherwise you need to delete cookies after
every session) Make a page like:
<?php
session_register("count");
$count += 10;
?><html><body>
<a href="thispage.php">This page</a> Count = <?php echo $count; ?>
</body>
</html>
Count should be 10 on first hit and +10 each time you click on the link (assuming trans-sid for that
link to work right w/out cookies, but trans-sid isn't involved in this bug) to "This
page": but if you fake a URL, "thispage.php?count=234" then on the first run, $count
will display as 244 (since the script will add 10 to it...)
This can be avoided by unsetting (or setting for that matter) the registered variable(s) before
session_register() (and maybe before session_start, haven't checked), but that should NOT be
necessary: PHP should unset the variable by itself on first run.
---------------------------------------------------------------------------
Full Bug description available at: http://bugs.php.net/?id=9020