Session (security) problem!

[Anon]

I've been succesfully trying this session stuff; and it all (seem to) work
perfectly.

However, this problem occured:

• I logged in to my account, PHP created a session variable like
  "bla.php?PHPSESSID=3498baef4949[etc]"
• I then copied this URL into a text file, and ran over to another computer.
  Entered the very same url
• I was immediately logged in as the webmaster having full access to all
  adminstration possibilities.

The reason why I tried this was that after doing some online testing, my
Nedstat referer tracker picked up my url, in which he also included the
PHPSESSID=xx as part of the url-referer.

Now, correct me if I'm wrong, but shouldn't PHP destroy the session as soon
as the user logs off, or exits his browser? And shouldn't PHP create a
unique session id every time you log in?

The reason why I used the session id in the URL and not in <input
type="hidden" name="PHPSESSID" etc. is because I use several links in the
menu of the administration, those are hyperlinks and I did not want to
create a <form></form> for each option in the administration menu.

Exposing the PHPSESSID in the URL shouldn't be a problem I think, since it
should be unique and be destroyed / rendered invalid after a user logs off
or exits his/her browser.

Can someone tell me what's wrong? The code is quite easy, every page has :

include "includefile.php";

And the include file has this:

session_start();
session_register("value");

Greetings,
Martin.

[Anon]

so far as i can tell, the problem is this:

despite the fact your browser may have been closed down, the session hadn't been destroyed. a logout page could accomplish this, as well as a shorter timeout (although i don't know the details of how to do the latter)

you could also use cookies to store the session ID, but you will be limiting your browser audience.

--
rad

[Anon]

Hi,

First of all, thank you for answering.

However; even after 2 hours I can still resolve the page and get logged in as the one who created the session earlier.

Also, I indeed don't want to depend on cookies; infact I test my pages with cookies turned off to make sure it works.

And, it does work, but if your cookie session is send through an URL and users simply click this URL from any weblog tracker/visitor statistics program like Nedstat, it shouldn't let anyone log in.

The log out page used to look like this:

session_start('login');
session_destroy('login');

I've changed it to this:
unset($login['login']);

Both accomplish nothing, if I cut & paste the URL before I log out which includes the session id, I still am able to access the page as the webmaster, and so is the computer next to me ;-(

I'm kind of running into walls at the moment so any help is appreciated ;-)

Perhaps my PHP.INI is wrong this is what it says about sessions:

session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1

session.name = PHPSESSID

session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /

session.cookie_domain =

session.serialize_handler = php

session.gc_probability = 1

session.gc_maxlifetime = 1440
session.referer_check = ; I've changed this to 1 without success
session.entropy_length = 0

session.entropy_file =

session.cache_limiter = nocache
session.cache_expire = 180

Greetings,
Martin.

[Anon]

hi martin,

i just started working with sessions in php and think the same about them like you: they are not save ! Anyway, I haven't considered my page so important that I need to fix this securityhole totaly. But I think you can do a few changes to your php.ini...

session.use_cookies = 1 <- if you don't want to use cookies, set it to 0 ..
session.gc_probability = 1 <- if you want php to destroy the garbage (old session data) on every new session start set it to 100 (%)
session.gc_maxlifetime = 1440 <- this is the lifetime of your stored session data set it to 0 ... combined with gc_probability = 100 the session-data shouldn't live too long :-)

i haven't tested those settings yet, because i think a lifetime of 1440 and a gc_probability of 50 is ok, but it should work ... hope so :-)

cya Rob

[Anon]

hi martin,

i just started working with sessions in php and think the same about them like you: they are not save ! Anyway, I haven't considered my page so important that I need to fix this securityhole totaly. But I think you can do a few changes to your php.ini...

session.use_cookies = 1 <- if you don't want to use cookies, set it to 0 ..
session.gc_probability = 1 <- if you want php to destroy the garbage (old session data) on every new session start set it to 100 (%)
session.gc_maxlifetime = 1440 <- this is the lifetime of your stored session data. set it to 0 ... combined with gc_probability = 100 the session-data shouldn't live too long :-)

i haven't tested those settings yet, because i think a lifetime of 1440 and a gc_probability of 50 is ok, but it should work ... hope so :-)

cya Rob

[Anon]

hi martin,

i just started working with sessions in php and think the same about them like you: they are not save ! Anyway, I haven't considered my page so important that I need to fix this securityhole totaly. But I think you can do a few changes to your php.ini...

session.use_cookies = 1 <- if you don't want to use cookies, set it to 0 ..
session.gc_probability = 1 <- if you want php to destroy the garbage (old session data) on every new session start set it to 100 (%)
session.gc_maxlifetime = 1440 <- this is the lifetime of your stored session data. set it to 0 ... combined with gc_probability = 100 the session-data shouldn't live too long :-)

i haven't tested those settings yet, because i think a lifetime of 1440 and a gc_probability of 50 is ok, but it should work ... hope so :-)

cya Rob

[Anon]

Hi Rob,

You know the button says "press once to submit" ;-))) Even if it takes a long time to post -grin-

But thanks for answering. Yes, I did think about what you said and the changes to make to php.ini. That's all fine for now, but as soon as our server get's busy with all sorts of PHP programs it will take alot of CPU work to kill all sessions if you set GC probability to 100% to kill the garbage.

I'm not sure how much it effects the CPU, but they didn't put it on only 1% for nothing I guess.

Why sessions are not automatically deleted after a logout or browser exit is really beyond me.

And all the things you said seem logical, but doesn't guarantee you anything. It's the "best" solution so far but hardly secure. It doesn't guarantee you that the next person get's your session id even while you are still logged in.

I was thinking I did something wrong, but it's beginning to dawn on me that sessions are just not secure and are nice for telling you how much you have in your "shopping basket" but are dangerous to use for login and password security.

Rats, and I really thought I had found the clue to not using cookies. Now I have to start all over again.

[Anon]

Hi Martin,

sorry for posting the answer three times ... (it wasn't that interesting :-)). But I think you are right with your suggestions about perfomance ... (buy a bigger server then :-).

I think it would be best, if you don't use sessions at all, they are ment to simplify your homepage-construction not to make a real secure access control... I thought about using SSL in the sensible part of my page... but have no idea how ... anyway as soon as I find a real secure way I tell you about it ... but don't expect too much I am working with PHP for a month now ...

cya Rob

[Anon]

I just wanted to add that what you brought up is really interesting.
Of course a web page with sensitive data need security and maybe sessions isn't the answer but a secure server (see other Apache projects). However, I've done session management in PHP on a couple of sites that don't really have much sensitive data.
I've of course also tried to "break" into them the way you described Martin. As far as I can tell that is pretty hard.

My only suggestion really is to see the session management article on this site. If you've followed it and still not been able to fix it then by all means go for the Apache Secure Server (or something else)

[Anon]

To make sessions secure enough for semi-sensetive information, you essentially have to limit a session to one physical computer (as best you can). I do this by establishing the following security check:

In addition to the client presenting a valid session ID to the server, via either the URL or a cookie, one of the following must happen:

a) The client must also present a password which was placed in a cookie, OR

b) The first two portions of the client's IP address must match the IP that it had when the session began. (e.g., if your IP was 192.168.0.1 when you started the session, it would have to begin with 192.168 everytime you tried to access the session again.)

With this security check in place, it doesn't matter if I Instant Message my URL to a friend, or if someone reads it over my shoulder (or whatever). They will not be able to pass either security check, and so they will not be allowed into the session. Of course there are caveats, such as computers on the same network sharing an IP, etc. But this kind of ID system will never be perfect. This is why I said it works for semi-sensetive material.

The point of this system is that it provides excellent protection against session "hijacking", while allowing virtually anyone to maintain a session of their own.

The only time you would be unable to establish a session of your own, is if you were to:

a) turn off cookies, AND

b) jump some serious IP's

But if this is a concern for you, you could always give users an option (say, at login if using this for auth) to forgo the extra security. Or maybe check whether the client accepts cookies and lighten the rules a bit if it doesn't. Very customizable solution.