In computer science , session hijacking , sometimes also known as cookie hijacking , is the exploitation of a valid computer session -sometimes also called a session key -to gain unauthorized access to information 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 , since HTTP cookies [1], used to maintain a session on many websites can be easily stolen by an attacker using an intermediary computer or with access to saved cookies on the victim's computer (see HTTP cookie theft ). After successfully stealing the relevant session cookies, the attacker can use the Pass the Cookie method to carry out session hijacking. [2]
A popular method uses IP packets with source routing . This allows an attacker at point B on the network to participate in a dialogue between A and C , causing IP packets to pass through machine B.
If source routing is disabled, the attacker can use "blind" hijacking, in which he guesses the responses of the two machines. In this way, the attacker can send a command, but will never see the response. Nevertheless, a common command would be to set a password allowing access from other sources on the network.
The attacker can also be "embedded" between A and C, using a program to monitor the conversation. This is known as a "man in the middle" attack.
Methods [ edit ]
There are four main methods used to hijack a session. 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 containing a specific session ID. Now the attacker only needs to wait for the user to log in.
- Session sidejacking , where the attacker uses packet analysis to read network traffic between two parties in order to steal the session cookie . Many websites use SSL encryption for login pages, so that attackers cannot see the password, but do not use encryption for the rest of the site after authentication . This allows attackers who can read network traffic to intercept all data sent to the server, or web pages viewed by the client. Since this data includes the session cookie , it allows them to impersonate the victim, even if the password itself is not compromised. [ Unsecured Wi-Fi hotspots are especially vulnerable, since anyone sharing the network can usually read most of the web traffic between other nodes and the access point .
- Cross-site scripting , in which the attacker tricks the user's computer into running code that is considered trusted because it appears to belong to the server, allowing the attacker to obtain a copy of the cookie or perform other operations.
- Malware and unwanted programs can use browser hijacking to steal browser cookies without the user's knowledge, and then perform actions (such as installing Android applications) without the user's knowledge. An attacker with physical access can simply try to steal the session key, for example by obtaining the contents of a file or the memory of the relevant part of the user's computer or the server.
After successfully obtaining the relevant session cookies, the attacker can use the Pass the Cookie method to carry out session hijacking.
Prevention
Methods for preventing session hijacking include:
- Encrypting the data traffic passed between parties using SSL / TLS ; in particular the session key (although ideally all traffic for the entire session [11] ). This method is widely used by online banks and other e-commerce services, since it fully prevents sniffing-style attacks. Nevertheless, it would still be possible to carry out some other kind of session hijacking. In response, researchers from Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by binding the application session to the SSL / TLS credentials.
- Using 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 session fixation, since the attacker does not know the user's session ID after they have logged in.
- Some services perform secondary checks on the user's identity. For example, a web server may check on every request whether the user's IP address matches the one last used during that session. However, this does not prevent attacks from someone using the same IP address, and can frustrate users whose IP address may change during a browsing session .
- Alternatively, some services will change the cookie value on every request. This significantly reduces the window in which an attacker can act, and makes it easy to determine whether an attack has taken place, but can cause other technical issues (for example, two legitimate, tightly synchronized requests from the same client can result in a token validation error on the server).
- Users may also want to log out of websites when they are finished using them. However, this will not protect against attacks such as Firesheep.
Comments