Re: Session

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi -

John W. Holmes wrote:
The session does not exist past the point of closing the browser unless you
increase the lifetime of the session cookie itself. I would recommend you
just leave it at zero, though, meaning it only persists for as long as the
browser window is open. The longer you make the sessions last, the easier it
is for someone to hijack them.

One point of clarification here. The *cookie* doesn't exist past the point of closing the browser, but the session file (assuming using files) will continue to exist until it has been garbage collected or until session_destroy() is called. Also, if you weren't using cookies (were passing session id in URL) you could open your browser again and navigate back using your history & you'd still be logged in. That's why it's a good idea to always call session_destroy() when a user logs out. That will effectively delete all session data on the server.


Of course, as John mentions, once the user closes the browser the in-memory cookie will be deleted and (if you're using only cookies) there's no longer any connection between that client computer and the session stored on the server. In that respect the "session" exists no longer, but as mentioned the data will still be there on the server. If someone knows (e.g. hijacker) the session ID, they can revive the session by just adding it to the URL.

On that note, here are a few things you might want to consider if you want to make sessions more secure:

- use only cookies for sessions. (session.use_only_cookies = 1) This prevents the session ID from *ever* being added to the URL. URLs get logged -- by apache, by proxy servers, by user bookmarks :) -- and if a URL contains a session ID then you have that mentioned problem where a session can be easily revived after the user closes the browser (effectively session hijacking, intentional or not).

- regenerate the session id when a user logs in. simply run session_regenerate_id() after the username/password has been verified. This goes a long way to prevent session fixation, another type of session attack in which an attacker makes a user log in using a fixed session id (e.g. by clicking on a link that includes something like &PHPSESSID=1234); once the user logs in using this fake session id, the attacker can use that session id in order to have access to the system as whichever user logged in. (Do a search on "session fixation" for more information on that.)

- keep your gc_maxlifetime as small as possible; that way if a user does close their browser their session won't remain active for 12+ hours. You might want to consider ways of periodically refreshing the page using an iframe or even just a <meta refresh...> solution. That will address the need to stay logged-in while the browser is open, while also allowing you to have a very brief session lifetime.

Hans

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux