Reputation: 2133
This could be a basic concept but I am bit confused over it.
Guidelines tell us to regenerate the session ID after user login in order to make it usable if it is being sniffed over the network thus preventing a replay attack.
My point is that even after the session ID is regenerated it would again be stored in a user browser and if an attacker or some other person who has access to the user's system he could copy that cookie and replay in another browser to gain post login access irrespective of TLS/NON TLS connections?
is it correct to say that this kind of activity can not be prevented?
Suggestions/Views please?
Upvotes: 0
Views: 246
Reputation: 14752
Of course, if you're being sniffed - you're being sniffed, and you can't do anything about that, except for encrypting the traffic.
ID regeneration does help mitigate replay attacks if done regularly (i.e. not just on login or privilege changes, but on regular time intervals), but traffic sniffing is just one way of hijacking sessions, not all of them.
A cookie may be planted into a victim's browser (aka session fixation), which is primarily what ID regeneration on login prevents.
A cookie may also be stolen/leaked via another vulnerability in the application.
A session ID may be deterministically guessed under some circumstances (timing side-channel attacks, insufficient randomness, or even plain brute force).
The goal of ID regeneration is to start a clean session, that an attacker cannot have hijacked already.
Upvotes: 3