Session Hijacking

Session hijacking, as the name suggests, all about knows the session ID (SID) of an active user so that his account can be impersonated or hijacked. After a user enters his credentials, the application tries to identify him only based on his cookie value (which contains the SID). Hence, if this SID value of any active user is known to us, we can use the same and login to the application as a victim and thus get access to all of the information. And if session ID is gone, everything is gone!

An attacker who manages to obtain a valid ID of user’s session can use it to directly enter that session – often without arising user’s suspicion. Interestingly, most cross-site scripting proof-of-concept exploits focus on obtaining the session ID stored in browser’s cookie storage. This class of attacks, where the attacker gains access to the user’s session by obtaining his session ID, is called sessionhijacking

We can perform Session Hijacking by

MITM (Man in Middle Attack)

XSS (Cross Site Scripting)

 Methods to prevent session hijacking include:

• 1: Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key (though ideally all traffic for the entire session). This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack. In response, scientists from the Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by correlating the application session with the SSL/TLS credential
• 2: Use of a long random number or string as the session key. This reduces the risk that an attacker could simply guess a valid session key through trial and error or brute force attacks.
• 3: Regenerating the session id after a successful login. This prevents session fixation because the attacker does not know the session id of the user after s/he has logged in.
• 4: Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.
• 5: Users may also wish to log out of websites whenever they are finished using them