session_regenerate_id - what if bad guy regenerates first ?

[scanreg]

session_regenerate_id

 

what if a bad guy traps a session id and then goes to that site and clicks something on that site before the original user triggers a new session id? (original user is just sitting on a page for instance)

 

might the bad guy trigger a session regenerate first and thus block out the original user?

 

thanks

[lemmin]

By default, the old session id is still available, so not unless the delete flag is specified. There is a lot more information in the comments on this function's page:

 

http://php.net/manual/en/function.session-regenerate-id.php

[xyph]

session_regenerate_id

 

what if a bad guy traps a session id and then goes to that site and clicks something on that site before the original user triggers a new session id? (original user is just sitting on a page for instance)

 

might the bad guy trigger a session regenerate first and thus block out the original user?

 

thanks

 

Yes, the attacker would hijack the active session, and the legit user's session would be orphaned.

 

When the user logs back in and generates a new session ID, the attacker's hijacked ID would then be orphaned.

[scanreg]

thanks both

 

1. if you set to delete the old session:

 

session_regenerate_id(TRUE);

 

does this delete just the session id, or does it delete all the data associated with the old id too?

 

there's a comment over in the php.net link mentioned by lemmin that states:

 

session_regenerate_id(TRUE);

/* erase data carried over from previous session */

 

so i'm concerned that all the data would get zapped too

 

2. what if you had the same scenario mentioned originally but now the session_regenerate_id is set to delete the old id (or id and data, whichever it is) (TRUE), what if the original user triggers a session regenerate first, thus deleting the old session id, but the bad guy after that then clicks a page, what happens to the bad guy? does it generate a session id but that new bad-guy session is untied to the original user, thus keeping the bad guy out?

 

thanks

[Christian F.]

I'm sitting here wondering how the attacker would trigger the session regenerate, in order to make this a real problem?

Normally you regenerate the ID as soon as you've verified that the login information is correct, which means within the same request as the login data got sent to the server. So if an attacker is to initiate a session regeneration, then he'd have to know the login info in the first place. In which case, the session regeneration is not your actual problem.

 

So, if you could explain a bit more on why/how this would be a real problem, it would be much appreciated. Most likely, if it is, then you're doing something wrong.

[xyph]

Some paranoid people will regenerate the session ID with each request. It helps prevent active theft, because any activity on the attackers end would kick the user out. The attacker would have to wait for the user to go idle, or hope they don't actively destroy the session (logout) when they're done.

[scanreg]

well, i'm thinking that perhaps it would be good to tie the session to the originating ip

 

if original-ip + session, then display good stuff

else bye

 

since the ip is merely detected by the server but not sent in the data stream

[xyph]

Multiple users can have the same IP.

 

Users can change IP on a per request basis.

 

It's a decent solution, but it might piss off certain users, and won't help if the attack is performed on the same local network.

[scanreg]

Multiple users can have the same IP

 

yeah, was thinking that too, though wasn't aware that users can change ip on a per request basis, thanks for that info

 

any thoughts on how to better approach this?

 

thanks

[xyph]

There's not that much that can be done to prevent MitM attacks. It's more of a security issue outside of your control.

 

Even with IP checking, an attacker can spoof the originating IP, and perform whatever actions he needs to without the server knowing its coming from elsewhere... Since the attacker generally doesn't care about the response, just performing the action itself.

[scanreg]

Ah, thanks, so perhaps requiring login first would be better per ChristianF

 

So if an attacker is to initiate a session regeneration, then he'd have to know the login info in the first place.

[xyph]

An attacker regenerating a session isn't a big issue, the session is stolen regardless. With a regenerated ID, at least the user will instantly know.

[scanreg]

An attacker regenerating a session isn't a big issue, the session is stolen regardless. With a regenerated ID, at least the user will instantly know.

 

thanks

 

the main thing is that we'd like to display cart contents and other cart features to just the authenticated user