2 edited body
source | link

That's not how a session fixation attack works. The attacker must first trick the user into visiting the website using a predetermined session. For example, I could trick you into clicking a shortened link http://example.com/index.php?PHPSSIDE=BLAHBLAHBLAH. If you login to example.com now, your session will be identified by BLAHBLAHBLAH. I'd then simply use the same identifier and login to your session. Other methods include an untrusted sub-domain assigning a session cookie for another sub-domain.

If you trust your sub-domains, just configuring your web server not to use session identifiers (eg. PHPSSID) in GET or POST is enough. Pairing the session to an IP address, refreshing the identifier, and session expiry, are all also good extra layers of protection against session hijacking.

When implementing a security feature, always think about the majority of your users. Those 90+% who'swhose IP won't change a gazillion time throughout the session, those who won't have their sessions constantly hijacked. For the other 10%, it's alright to show them a re authentication form (entering the password again) when something specious happens.

That's not how a session fixation attack works. The attacker must first trick the user into visiting the website using a predetermined session. For example, I could trick you into clicking a shortened link http://example.com/index.php?PHPSSIDE=BLAHBLAHBLAH. If you login to example.com now, your session will be identified by BLAHBLAHBLAH. I'd then simply use the same identifier and login to your session. Other methods include an untrusted sub-domain assigning a session cookie for another sub-domain.

If you trust your sub-domains, just configuring your web server not to use session identifiers (eg. PHPSSID) in GET or POST is enough. Pairing the session to an IP address, refreshing the identifier, and session expiry, are all also good extra layers of protection against session hijacking.

When implementing a security feature, always think about the majority of your users. Those 90+% who's IP won't change a gazillion time throughout the session, those who won't have their sessions constantly hijacked. For the other 10%, it's alright to show them a re authentication form (entering the password again) when something specious happens.

That's not how a session fixation attack works. The attacker must first trick the user into visiting the website using a predetermined session. For example, I could trick you into clicking a shortened link http://example.com/index.php?PHPSSIDE=BLAHBLAHBLAH. If you login to example.com now, your session will be identified by BLAHBLAHBLAH. I'd then simply use the same identifier and login to your session. Other methods include an untrusted sub-domain assigning a session cookie for another sub-domain.

If you trust your sub-domains, just configuring your web server not to use session identifiers (eg. PHPSSID) in GET or POST is enough. Pairing the session to an IP address, refreshing the identifier, and session expiry, are all also good extra layers of protection against session hijacking.

When implementing a security feature, always think about the majority of your users. Those 90+% whose IP won't change a gazillion time throughout the session, those who won't have their sessions constantly hijacked. For the other 10%, it's alright to show them a re authentication form (entering the password again) when something specious happens.

1
source | link

That's not how a session fixation attack works. The attacker must first trick the user into visiting the website using a predetermined session. For example, I could trick you into clicking a shortened link http://example.com/index.php?PHPSSIDE=BLAHBLAHBLAH. If you login to example.com now, your session will be identified by BLAHBLAHBLAH. I'd then simply use the same identifier and login to your session. Other methods include an untrusted sub-domain assigning a session cookie for another sub-domain.

If you trust your sub-domains, just configuring your web server not to use session identifiers (eg. PHPSSID) in GET or POST is enough. Pairing the session to an IP address, refreshing the identifier, and session expiry, are all also good extra layers of protection against session hijacking.

When implementing a security feature, always think about the majority of your users. Those 90+% who's IP won't change a gazillion time throughout the session, those who won't have their sessions constantly hijacked. For the other 10%, it's alright to show them a re authentication form (entering the password again) when something specious happens.