Session variables open to attack with compromised session id?

jonchakra5

Greetings!

If someone nabs your session id, how valnerable are your remaining session variables? I have globals on unfortunately (although ahundiak has suggested a possible way around that), but I am interested in knowing how easy it is to get at session variables and/or dummy them up.

If I am calling a session variable with $SESSION, can it still be hacked? That is, if I am actually getting a session value, and setting it within my script with $SESSION.

Also it would seem ssl would make getting the session id more difficult in the first place. Have I got that right?

Thanks for your replies!

dalecosp

Hmmmm, so, someone is sniffing a browser session and picks up your sessionID? Seems like an outsider would need some clue as to the name of the individual vars. Of course, if he'd visited the site, and saw GET vars, for example, he'd have a clue.

Nothing is impenetrable, I suppose. However, since session vars are stored on the server, it'd be rather difficult, and above the level of your average script kiddie (#include disclaimer.h)

SSL would help in that sniffing the browser session and gaining the session ID would be nearly impossible....

KDK

jonchakra5

dalecosp

Thanks for the reply! Very informative. Makes me feel better about my whole setup. Tell me, why is there the conception that php sessions are inherently insecure?

minorgod

<rant>
Why is there a misconception about PHP security? Because people who program those other scripting languages (insert your most hated microsoft scripting technolgy here) love to spread misinformation whenever they hear it. It makes them feel better about not having a clue about security. They hear a rumor on slashdot that PHP has a security hole and they jump for joy because for once, it's not their MS technology being blasted. What they never bother to do is followup and find out how quickly the PHP SSL patch is released that fixes the security problem. Meanwhile they are completely oblivious to the fact that IIS is completely insecure and because it's closed source, they most likely will either never hear about it and will simply download the next IIS patch that comes out whenever Microsoft decides to fix it. They'll watch MSNBC specials on how insecure Windows is and then they'll go to work the next day and pretend it's not an issue because they haven't got a clue how to fix it.

At least, that's my theory. Anyway, as far as I can tell from actual facts, PHP is as secure as any other server-side scripting language, bar none. Any security holes in your PHP applications are most likely due to flawed application design and have nothing to do with PHP. An insecure application written in PHP will be insecure in ASP too. The language itself makes no difference. ASP might have some specific Microsoft-patented encryption schemes or other proprietary "security features", but the functionality is generally duplicated in the open source world with the benefit that people can look at the code and see if it's really secure. So I'd even venture that PHP and other open-source applications running on an open-source OS are MORE secure than closed-source applications written in ASP running on the most notoriously insecure OS in history.

I guess you can probably tell I'm sick of hearing ignorant ASP/JSP/Java/ColdFusion programmers speculating in public about PHP security holes they know nothing about. I'll shut up now.
</rant>

dalecosp

Hmm, you must be a junior member only because you just discovered the forum 😉

I think that probably you've made some very good points there...of course, I'm not much for M$ way of doing things, either, although I s'pose I owe 'em a big thank you that everybody wants to surf the 'Net these days...but that's another thread entirely.

The main problem with security, on almost any platform, is that there's always someone out there who knows how to play 'cracker' better than you do yourself..... :eek:

How'd you dig up this old thread, anyway? 🙂

minorgod

I just stumbled across it while searching for "SSL session". I was trying to figure out why I was losing my session vars when I switched to an SSL connection. Wrote custom session handlers to store info in database, but it wasn't registering. I finally figured out I was just redirecting to an invalid URL, but my sessions weren't lost after all. Now I just need to reload the session data when switching to the secure server. And on that note, do you know whether I should be passing my $sid or should I pass the $PHPSESSID variable to reload the session after switching servers? I've seen both used, but never know which one is better. I'm under the impression that both are automatic PHP variables. Any opinions?