php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #9020 Registered variables can be set in URL on first run
Submitted: 2001-01-31 00:35 UTC Modified: 2001-02-20 14:16 UTC
From: paul_kroll at hotmail dot com Assigned:
Status: Closed Package: Session related
PHP Version: 4.0.4pl1 OS: Linux/All?
Private report: No CVE-ID: None
View Add Comment Developer Edit
 [2001-01-31 00:35 UTC] paul_kroll at hotmail dot 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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-01-31 00:51 UTC] paul_kroll at hotmail dot com 
Ref: think this is what the person was getting at in bug 8184.
 [2001-02-20 13:57 UTC] 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-02-20 14:12 UTC] paul_kroll at hotmail dot 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 14:16 UTC] paul_kroll at hotmail dot 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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 16 19:01:31 2024 UTC