In computer science, session hijacking , sometimes also known as cookie hijack is a valid exploit of computer sessions - sometimes also called session keys - to get unauthorized access to information or services in a computer system. Specifically, this is used to refer to the theft of a magic cookie used to authenticate users to a remote server. This has special relevance for web developers, because the HTTP cookie used to maintain sessions across multiple websites can be easily stolen by an attacker using an intermediate computer or with access to cookies stored on the victim's computer (see HTTP cookie theft).
A popular method is to use source-routed IP packets. This allows the attacker at the point B on the network to participate in the conversation between A and C by pushing the IP packet to pass through B machine.
If source-routing is turned off, an attacker can use "blind" hijacking, in which he guesses the response of two machines. Thus, the attacker can send commands, but can never see the response. However, a common command is to set a password that allows access from elsewhere on the internet.
An attacker can also "inline" between A and C using the sniff program to watch the conversation. This is known as "man-in-the-middle attack".
Video Session hijacking
Sejarah HTTP
The HTTP protocols versions 0.8 and 0.9 have no cookies and other features required for session hijacking. The 0.9beta version of Mosaic Netscape, released on October 13, 1994, supports cookies.
Initial versions of HTTP 1.0 do have some security flaws associated with session hijackings, but they are hard to exploit because of the strangeness of most of the initial HTTP 1.0 servers and browsers. Because HTTP 1.0 has been set as a fallback for HTTP 1.1 since the beginning of 2000 - and since HTTP 1.0 server is essentially an HTTP 1.1 server, session hijacking issues have evolved into an almost permanent security risk.
The introduction of supercookies and other features with modernized HTTP 1.1 has enabled piracy issues to be a sustainable security issue. The webserver and the default browser state machine have contributed to this ongoing security issue.
Maps Session hijacking
Method
There are four main methods used for session hijacking. This is:
- Session fixation , where the attacker sets the user's session id to a known one, for example by sending an email to a user with a link containing a particular session id. The attacker now only has to wait until the user enters.
- Session cuts , where attackers use sniffing packets to read network traffic between two parties to steal session cookies. Many websites use SSL encryption for login pages to prevent an attacker from seeing passwords, but not using encryption for other parts of the site after being authenticated. This allows an attacker who can read network traffic to bypass all data sent to the server or web page viewed by the client. Because this data includes session cookies, it allows him to mimic the victim, even if the password itself is not compromised. Unsafe Wi-Fi hotspots are particularly vulnerable, as anyone who shares a network generally will be able to read most of the web traffic between other nodes and access points.
- Cross-site script creation , in which the attacker tricks the user's computer into running trusted code because it appears to belong to the server, allowing attackers to obtain copies of cookies or perform other operations.
- Malware and unwanted programs may use browser hijacking to steal browser cookie files without the user's knowledge, and then perform actions (such as installing Android apps) without the user's knowledge. An attacker with physical access can easily try to steal a session key by, for example, obtaining a file or memory content from the appropriate portion of either the user's computer or the server.
Exploit
Firesheep
In October 2010, a Mozilla Firefox extension called Firesheep was released which made it easier for session hijackers to attack unencrypted public Wi-Fi users. Websites like Facebook, Twitter, and anything that users add to their preferences allow Firesheep users to easily access personal information from cookies and threaten the private properties of public Wi-Fi users. Just a few months later, Facebook and Twitter responded by offering (and then needing) Secure HTTP across.
WhatsApp sniffer
An application named "WhatsApp Sniffer" is available on Google Play in May 2012, can show messages from other WhatsApp users connected to the same network as the app users. At that time, WhatsApp uses XMPP infrastructure with encrypted communications instead of plain text.
DroidSheep
DroidSheep is a simple Android tool for hijacking web sessions (sidejacking). It listens to HTTP packets that are sent over a wireless network connection (802.11) and extracts session IDs from these packets to reuse them. DroidSheep can capture sessions using libpcap libraries and supports: open network (unencrypted), WEP encrypted network, and WPA/WPA2 encrypted network (PSK only). This software uses libpcap and arpspoof. This apk is available on Google Play but has been removed by Google.
CookieCadger
CookieCadger is a graphical Java application that automates the sidejacking and replay of HTTP requests, to help identify leakage of information from applications that use unencrypted GET requests. It is a cross-platform open-source utility based on the Wireshark suite that monitors wired Ethernet, unsafe Wi-Fi, or loads a capture packet file for offline analysis. Cookie Cadger has been used to highlight the weaknesses of youth sharing sites like Shutterfly (used by AYSO football leagues) and TeamSnap.
Prevention
Methods to prevent session hijacking include:
- Encrypt data traffic passed between parties using SSL/TLS; especially session keys (though all traffic is ideal for the entire session). This technique is widely relied upon by web-based banks and other e-commerce services, as it completely prevents sniff-style attacks. However, it is still possible to perform some other types of session hijacking. In response, scientists from Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by linking application sessions with SSL/TLS credentials
- Use of long random numbers or strings as session keys. This reduces the risk that an attacker can easily guess a valid session key through trial and error or a brute force attack.
- Stretch the session id after you've successfully logged in. This prevents session fixation because the attacker does not know the user id session after s/he enters.
- Some services perform secondary checks on the user's identity. For example, a web server can check with every request that the user's IP address matches the last one used during the session. This does not prevent attacks by someone sharing the same IP address, however, and can be frustrating for users whose IP addresses are likely to change during the browsing session.
- Alternatively, some services will change the cookie value with each and every request. This dramatically reduces the window in which the attacker can operate and makes it easy to identify whether an attack has occurred, but may cause other technical issues (for example, two legitimate and short-term requests from the same client can lead to an error check on server).
- Users may also want to quit the website when finished using it. However this will not protect against attacks like Firesheep.
See also
- ArpON
- Cross-site request forgery
- HTTP cookies
- TCP sequence prediction attack
References
Source of the article : Wikipedia
0 Comments