Blog Topic 1 - Session Hijacking

Hypertext Transfer Protocol
- What is “session hijacking”? What are its security threats?
- How can web developers avoid it?

Session hijacking describes all methods by which an attacker can access another user's session. In computer science, session hijacking refers to 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. The HTTP cookies used to maintain a session on many web sites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim's computer.

TCP session hijacking happens when a hacker takes over a TCP session between two machines. Since most authentications only occur at the start of a TCP session, this allows the hacker to gain access to a machine.

A popular method is using source-routed IP packets. This allows a hacker at point A on the network to participate in a conversation between B and C by encouraging the IP packets to pass through its machine.

If source-routing is turned off, the hacker can use "blind" hijacking, whereby it guesses the responses of the two machines. Thus, the hacker can send a command, but can never see the response. However, a common command would be to set a password allowing access from somewhere else on the net.

A hacker can also be "inline" between B and C using a sniffing program to watch the conversation. This is known as a "man-in-the-middle attack".

A common component of such an attack is to execute a denial-of-service (DoS) attack against one end-point to stop it from responding. This attack can be either against the machine to force it to crash, or against the network connection to force heavy packet loss.

There are three main methods used to perpetrate a session hijack.

Session fixation,

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 particular session id. The attacker now only has to wait until the user logs in.

Example of Session fixation: http://www.china.org.cn/china/2010-06/29/content_20380883.htm

Email with link to fraudulent website with the domain name "www.hkboc.net", which looks similar to the official website of Bank of China (Hong Kong) Limited (BOCHK) “www.bochk.com”.

Session sidejacking,

where the attacker uses packet sniffing to read network traffic between two parties to steal the session cookie. Many web sites use SSL encryption 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 attackers 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 session cookie, it allows him to impersonate the victim, even if the password itself is not compromised. Unsecured Wi-Fi hotspots are particularly vulnerable, as anyone sharing the network will generally be able to read most of the web traffic between other nodes and the access point.

Alternatively, an attacker with physical access can simply attempt to steal 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 running 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 operations.

Example of Cross-Site Scripting

To initiate the attack, the attacker must convince the user to click on a carefully crafted hyperlink, for example, by embedding a link in an email sent to the user or by adding a malicious link to a newsgroup posting. The link points to a vulnerable page in your application that echoes the unvalidated input back to the browser in the HTML output stream. For example, consider the following two links.

Here is a legitimate link:

www.awebapplication.com/logon.aspx?username=bob

Here is a malicious link:

www.awebapplication.com/logon.aspx?username=<script>alert('hacker code')</script>

If the Web application takes the query string, fails to properly validate it, and then returns it to the browser, the script code executes in the browser. The preceding example displays a harmless pop-up message. With the appropriate script, the attacker can easily extract the user's authentication cookie, post it to his site, and subsequently make a request to the target Web site as the authenticated user.

There is something that the web developer can do to avoid the session hijacking.

Implement logout functionality to allow a user to end a session that forces authentication if another session is started.

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 he has logged in.

Encryption of the data passed between the parties such as using SSL thought out the communication; in particular the session key. 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.

Limit the expiration period on the session cookie if you do not use SSL. Although this does not prevent session hijacking, it reduces the time window available to the attacker.

Change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems. However, it prevents the back button from working properly on the web.

Perform thorough input validation, to prevent cross-site scripting, the applications must ensure that input from query strings, form fields, and cookies are valid for the application. Consider all users input as possibly malicious, and filter or sanitize for the context of the downstream code. Validate all input for known valid values and then reject all other input. Use regular expressions to validate input data received via HTML form fields, cookies, and query strings.

Use HTMLEncode and URLEncode functions to encode any output that includes user input. This converts executable script into harmless HTML.

Reference:
http://en.wikipedia.org/wiki/Session_hijacking
http://msdn.microsoft.com/en-us/library/ff648641.aspx
http://hackwithstyle.blogspot.com/2010/09/side-jacking-hack-accounts-on-lan-or.html
http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part3.html
http://msdn.microsoft.com/en-us/magazine/cc300500.aspx
http://shiflett.org/articles/session-hijacking
http://searchstoragechannel.techtarget.com/generic/0,295582,sid98_gci1250226,00.html


http://www.china.org.cn/china/2010-06/29/content_20380883.htm

http://www.securitytube.net/Web-Application-Session-Hijacking-Demo-video.aspx
http://www.youtube.com/results?search_query=session+hijacking&aq=f