Page 1 of 1

session_register() vs $_SESSION

Posted: Fri Aug 22, 2003 11:13 am
by PixelMaster
Ok ... I've read every last scrap of documentation on the session functions, and $_SESSION, and am trying to get into the nuances of the differences between the two.

To my eye, the only real difference between

Code: Select all

session_start();
$foo = $_POST['foo'];
$_SESSION['foo'] = $variable;
and

Code: Select all

session_start();
$foo = $_POST['foo'];
session_register('foo');
is that in the first example $foo is local, while it has become global (as $_GLOBAL['foo']?) in the second one. Or am I missing some subtle behaviour that they don't tell you about in the documentation?

Putting aside personal preference, and provided that all data is validated, how can using the superglobal $_SESSION be better than, or 'recommended' over creating a global with session_register()?

Posted: Fri Aug 22, 2003 11:34 am
by nielsene
The PHP group is trying to deprecate the user of session_register, I beleive. So you should use $_SESSION.

Personally I liked the functional form, better, but....

Posted: Fri Aug 22, 2003 4:00 pm
by JAM
Well, about the difference...
Here you user a form's name="foo" to set $foo, and the register it as a session-var:

Code: Select all

session_start(); 
$foo = $_POST['foo']; 
session_register('foo');
and the same thing, rewritten:

Code: Select all

session_start(); 
$_SESSION['foo'] = $_POST['foo'];
You typed $variable in you later example, but i think that you intended to use $foo there (?).

About the actual recommendations about globals or not... (Deep thoughts but...) ...I think that it's an security issue. Something that is
globalized is probably easier to forge, than the superglobals (here; $_SESSION) that is something put-aside for what it's really intended for.

Just take the $_POST's example:

Code: Select all

// old, now bad
if ($submittedinfo) { ... }
// new, better
if ($_POST['submittedinfo']) { ... }
What makes the first example not come from a GET? There must be the same sorts of issues with the sessions...

But again, far from an expert, but likes the discussion.

Posted: Sat Aug 23, 2003 8:19 am
by PixelMaster
Yeah ... I meant $foo, not $variable ...

Just thinking out loud here (cogs grind, smoke billows): ... suppose you have register_globals ON (not the way it should be, but suppose) ... then you register some variable, say ... $status, with session_register('status') ... now $status is global. Since PHP Enemy #1 is set to ON, if an attacker sends a variable 'status=fubar' in a COOKIE, GET, or POST, then how does the script know the difference between the one you set with session_register, and the one that the attacker, via register_globals, just set for you? (Yes, that's a recap of JAM's post, but humour me ...)

That makes sense ... but if you're checking your variables (as all good PHPers do :cool: ) ... how does that change anything? Does register_globals get first dibs at the data, before you get to validate it? A quick look at the manual, leads me to believe that, in fact, this is the case. Ok ... then why do they even give people a choice? I mean, why don't they just remove the register_global functionality altogether?

(More thinking out loud): Then, because the only way to be sure you're using a clean value consistently with a session, would be to use a variable from a place that only the script has access to, the $_SESSION superglobal was introduced. Of course, you've still got to validate the values, or better ... set them yourself. But because $_SESSION requires a call to session_start(); before it's available, the attacker can't try to use register_globals to set a session variable for you with a request like: http://..../script.php?_SESSION['status']=fubar.

Ok ... I think I've more or less answered my own question ...

Thoughts, anyone?

Posted: Mon Aug 25, 2003 8:19 pm
by JAM
I like that "Loud Thinking", I do that myself, and thinking about trademarketing it. So bare with me.

Of course, there is functions like [url=http://se.php.net/manual/en/function.se ... stered.php]
session_is_registered[url] and other ways to check if the session really is a session. If none used, I don't think the PHP-parser can see if its a session or MrEvilCracker sending it thru $_GET. How, I dunno. Others with experience please enlighten me/us if I'm wrong.
I mean, why don't they just remove the register_global functionality altogether?
I think they are. But i guess we can't expect everyone to rewrite all codes in 2 version-changes.

I would extend those thoughts to "why not skip the entire session_start() function at all"? If $_SESSION is used, its used. Why start the session previously?

Posted: Fri Aug 29, 2003 3:16 pm
by PixelMaster
No kidding ... Thanks for your help, guys.

Posted: Fri Aug 29, 2003 3:34 pm
by Rook
My turn to think out loud...
"why not skip the entire session_start() function at all"
I understand that statement... but there are reasons to explicitly call the function... If you use cookies to reference the session variable (so you don't have to pass it through the url) then you have to call the session_start() function to kick things off and drop that cookie. Also you can dream up your very own session id before starting off the the session with that id.

As far as the original topic of using $_SESSION = vs. session_register(), I've always used the former rather than the latter. But then I started off with PHP 4.1.2, so most of what I learned was based on the 'new' teachings.

well, those are my thoughts.. like 'em or love 'em... they're still in my head!

- Rook.

hmmmmm

Posted: Fri Aug 29, 2003 7:37 pm
by coos
seems like a case of 'if it ain't broke, play with it until it is!'

ha ha!

:D