Session hijacking

From Wikipedia, the free encyclopedia

Jump to: navigation, search
The term session hijacking refers to the exploitation of a valid computer sessio
n - sometimes also called a session key - to gain unauthorized access to informa
tion or services in a computer system. In particular, it is used to refer to the
theft of a magic cookie used to authenticate a user to a remote server. It has
particular relevance to web developers, as the HTTP cookies used to maintain a s
ession on many web sites can be easily stolen by an attacker using an intermedia
ry computer or with access to the saved cookies on the victim's computer (see HT
TP cookie theft).
Contents
[hide]
* 1 Analysis
* 2 Methods
* 3 Prevention
* 4 See also
* 5 References
[edit] Analysis
Many web sites allow users to create and manage their own accounts, logging in u
sing a username and password (which may or may not be encrypted during transit)
or other authentication method. In order that the user does not have to re-enter
their username and password on every page to maintain their session, many web s
ites use session cookies: a token of information issued by the server and return
ed by the user's web browser to confirm its identity.
If an attacker is able to steal this cookie, they can make requests themselves a
s if they were the genuine user, gaining access to privileged information or cha
nging data. If this cookie is a persistent cookie, then the impersonation can co
ntinue for a considerable period of time. Of course, session hijacking is not li
mited to the web; any protocol in which state is maintained using a key passed b
etween two parties is vulnerable, especially if it's not encrypted.
[edit] Methods
There are four main methods used to perpetrate a session hijack. These are:
* Session fixation, where the attacker sets a user's session id to one known
to him, for example by sending the user an email with a link that contains a pa
rticular session id. The attacker now only has to wait until the user logs in.
* Sidejacking, where the attacker uses packet sniffing to read network traff
ic between two parties to steal the session cookie. Many web sites use SSL encry
ption for login pages to prevent attackers from seeing the password, but do not
use encryption for the rest of the site once authenticated. This allows attacker
s that can read the network traffic to intercept all the data that is submitted
to the server or web pages viewed by the client. Since this data includes the se
ssion cookie, it allows him to impersonate the victim, even if the password itse
lf is not compromised.[1] Unsecured Wi-Fi hotspots are particularly vulnerable,
as anyone sharing the network will generally be able to read most of the web tra
ffic between other nodes and the access point.
* Alternatively, an attacker with physical access can simply attempt to stea
l the session key by, for example, obtaining the file or memory contents of the
appropriate part of either the user's computer or the server.
* Cross-site scripting, where the attacker tricks the user's computer into r
unning code which is treated as trustworthy because it appears to belong to the
server, allowing the attacker to obtain a copy of the cookie or perform other op
erations.
[edit] Prevention
Methods to prevent session hijacking include:
* 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.
* Regenerating the session id after a successful login. This prevents sessio
n fixation because the attacker does not know the session id of the user after h
e has logged in.
* Encryption of the data passed between the parties; in particular the sessi
on key. This technique is widely relied-upon by web-based banks and other e-comm
erce services, because it completely prevents sniffing-style attacks. However, i
t could still be possible to perform some other kind of session hijack.
* 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 at
tacks by somebody who shares the same IP address, however, and could be frustrat
ing for users who's IP address is liable to change during a browsing session. Th
erefore, a better method is to store and check a hash value of the user's browse
r string.[citation needed]
* Alternatively, some services will change the value of the cookie with each
and every request. This dramatically reduces the window in which an attacker ca
n operate and makes it easy to identify whether an attack has taken place, but c
an cause other technical problems (for example, preventing the back button from
working properly, on the web).
Use of SecurID card, or other token based secondary authentication is useless as
protection against hijacking, as the attacker can simply wait until after the u
ser authenticates, then hijack the session.[2]