Reputation: 11
The common practice followed in authenticating and then session tracking involves using session id retrieved from the client and then comparing the user details stored in the database to match the session id, user agent details, IP etc. Now, if a hacker gets access to session token and guesses or extracts other details, can he impersonate the user? What steps we can take to prevent such attacks?
Upvotes: 0
Views: 520
Reputation: 15599
For most applications, getting the session token is enough, no further checks are usually implemented. The only thing that would make a very significant difference is checking the request source IP with the session token, that would actually increase security, but from a usability perspective it's a disaster - IP addresses for typical users change sometimes, also a lot of users may have the same external IP (like in certain ISPs, or corporate networks).
So yes, getting the session token allows an attacker to impersonate a user.
To prevent such attacks, session ids need to be generated with secure random generators (or even better, from real random sources, but that gets problematic at scale), and they need to be protected while in transit (https) and also when stored (httpOnly cookies). Of course sometimes other aspects are equally important, so different compromises can be made (like storing the token in say localStorage, but only a short-lived one, and storing a refresh token in a httpOnly cookie for the identity provider).
Most importantly, you should almost never implement this yourself, unless you have really special requirements (things that likely close to nobody wanted before). In all the other cases, you will find it already implemented on your technology stack in well-known libraries or frameworks that a lot of people tested - you should use those.
Upvotes: 1