Re: [php-49] Security question: benefits, if any, of using 'session_regenerate_id'

From: Damon
Sent on: Thursday, December 11, 2008 11:34 AM
One of the specific instances that session_regenerate_id is an attempt at fixing is related to phishing in an attack known as session fixation.

Say I send somebody to a site where PHP accepts session variables in the URL, i.e. http://somewhere.com/login?PHPSESSID=ffd36b5e04e10b6c[masked]ae7e1effc

If the session id isn't regenerated on different privilege changes (logins, password changes, etc), then I (the attacker) could use knowledge of that pre-seeded session id to assume the role of whatever user I targeted.

Obviously not accepting session id's via the URL is a good mitigation for this, but not always possible in real-world scenarios.

dpc

On Thu, Dec 11, 2008 at 10:55 AM, Mike Ree <[address removed]> wrote:
Ha, i forgot all about url sessions. This would be a probably the greatest example of when you would want to change your session id. But you never use url sessions to protect secure information. Only for goof off sites where the data isn't really too important.

From: [address removed] [[address removed]] On Behalf Of Richard [[address removed]]
Sent: Thursday, December 11,[masked]:48 AM

To: [address removed]
Subject: Re: [php-49] Security question: benefits, if any, of using 'session_regenerate_id'

The complexity of the session id is only a very small bit in session security and regenerating your session id on login is a very smart thing to do.

Session hijacking is easier then you might think.. Look through your referral logs a bit one day and you will find session ids for any site that links to yours AND passes session ids there URLS.

Sure cookie sessions negate this issue but no where did you mention that, you just claimed sessions are safe and to hard to steal to worry about.

Richard Thomas



On Dec 11, 2008, at 10:36 AM, Mike Ree wrote:

If your using php 5.1 or higher you can just use session_regenerate_id(true) instead of session_destroy, but that is a good point to make clear.
 
I personally think session hijacking which should be known of is very difficult to accomplish. The sessions are complex strings "ffd36b5e04e10b6c[masked]ae7e1effc" (example of my PHP 4.3.8 session string) which are only transmitted to the domain they are connecting into. To steal a session you have to have access to the server, the client, or somehow intercept the traffic. Chances of a session hijack are slim and I suggest to only safegaurd against on sites that contain highly secure information.
 
One common practice is to regenerate session id's on password or setting changes and to require password verification to change settings. This will stop a hijacker from changing the password and if the password is changed by the user remove a hijacker. Requiring password verification for secure actions will stop ill effects of a session hijack regardless. Will also stop station hijacks (when you leave the window open at work and forget you left yourself logged in).
 
Practice the above security measure and ensure that your sessions are either stored in a secure place and you should be good.
 
My 2 cents,
Mike




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Mike Ree ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Mike Ree, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Richard ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Richard, visit his/her member profile

To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Mike Ree ([address removed]) from The Seattle PHP Meetup Group.
To learn more about Mike Ree, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup Support: [address removed]
632 Broadway, New York, NY 10012 USA

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy