Session Hijacking - An Introduction

 

When a website successfully authenticates a user, the browser and the server open a session. A session is an HTTP conversation in which the browser sends a series of HTTP requests corresponding to user actions, and the web server recognizes them as coming from the same authenticated user without requiring the user to log back in for each request. If a hacker can access or forge session information that the browser sends, they can access any user’s account on your site. Thankfully, modern web servers contain secure session-management code, which makes it practically impossible for an attacker to manipulate or forge a session. However, even if there are no vulnerabilities in a server’s session-management capabilities, a hacker can still steal someone else’s valid session while it’s in progress; this is called session hijacking. 

Session hijacking vulnerabilities are generally a bigger risk than the authentication vulnerabilities discussed in the previous chapter, because again, they allow an attacker to access any of your users’ accounts. This is such a tantalizing prospect that hackers have found many ways to hijack sessions. 

How Sessions Work

To understand how an attacker hijacks a session, you first need to understand what happens when a user and a web server open a session. When a user authenticates themselves under HTTP, the web server assigns them a session identifier during the login process. The session identifier (session ID)—typically a large, randomly generated number—is the minimal information the browser needs to transmit with each subsequent HTTP request so the server can continue the HTTP conversation with the authenticated user. The web server recognizes the session ID supplied with each request, maps it to the appropriate user, and performs actions on their behalf. 

Note that the session ID must be a temporarily assigned value that’s different from the username. If the browser used a session ID that was simply the username, hackers could pretend to be any user they pleased. By design, only a very small minority of possible session IDs should correspond to a valid session on the server at any given time.  

Besides the username, the web server typically stores other session state alongside the session ID, containing relevant information about the user’s recent activity. The session state might, for example, contain a list of pages the user has visited, or the items currently sitting in their shopping basket. Now that we understand what happens when users and web servers open a session, let’s look at how websites implement these sessions. There are two common implementations, typically described as server-side sessions and client-side sessions. Let’s review how these methods work, so you can see where the vulnerabilities occur. 

Server-Side Sessions

In a traditional model of session management, the web server keeps the session state in memory, and both the web server and browser pass the session identifier back and forth. This is called a server-side session. 

Historically, web servers have experimented with transferring session IDs in multiple ways: either in the URL, as an HTTP header, or in the body of HTTP requests. By far, the most common (and reliable) mechanism the web development community has decided upon is to send session IDs as a session cookie. When using session cookies, the web server returns the session ID in the Set-Cookie header of the HTTP response, and the browser attaches the same information to subsequent HTTP requests using the Cookie header.

Cookies have been part of the HyperText Transfer Protocol since they were first introduced by Netscape in 1995. Unlike HTTP-native authentication, they’re used by pretty much every website under the sun. (Because of European Union legislation, you’ll be well aware of this fact: websites are required by European law to inform  you that they’re using cookies.)

Server-side sessions have been widely implemented and are generally very secure. They do have scalability limitations, however, because the web server has to store the session state in memory. That means that at authentication time, only one of the web servers will know about the established session. If subsequent web requests for the same user gets directed to a different web server, the new web server needs to be able to recognize the returning user, so web servers need a way of sharing session information.

 

Client-Side Sessions

Because server-side sessions have proven difficult to scale for large sites, web server developers invented client-side sessions. A web server implementing client-side sessions passes all session state in the cookie, instead of passing back just the session ID in the Set-Cookie header. The server serializes session state to text before the session state is set in the HTTP header. Often, web servers encode the session state as JavaScript Object Notation  (JSON)—and deserialize it when returning it to the server. 

Client-side sessions do create an obvious security problem, however. With a naive implementation of client-side sessions, a malicious user can easily manipulate the contents of a session cookie or even forge them entirely. This means the web server has to encode the session state in a way that prevents meddling. One popular way to secure client-side session cookies is to encrypt the serialized cookie before sending it to the client. The web server then decrypts the cookie when the browser returns it. This approach makes the session state entirely opaque on the client side. Any attempt to manipulate or forge the cookie will corrupt the encoded session and make the cookie unreadable. The server will simply log out the malicious user and redirect them to an error page. Another, slightly more lightweight approach to securing session cookies is to add a digital signature to the cookie as it’s sent. A digital signature acts as a unique “fingerprint” for some input data—in this case, the serialized session state—that anyone can easily recalculate as long as they have the signing key originally used to generate the signature. Digitally signing cookies allows the web server to detect attempts to manipulate the session state, since it’ll calculate a different signature value and reject the session if there has been any tampering.

 

How Attackers Hijack Sessions

Now that we’ve discussed sessions and how websites implement them, let’s look at how attackers hijack sessions. Attackers use three main methods to hijack sessions: cookie theft, session fixation, and taking advantage of weak session IDs.

Cookie Theft

With the use of cookies being so widespread nowadays, attackers normally achieve session hijacking by stealing the value of a Cookie header from an authenticated user. Attackers usually steal cookies by using one of three techniques:

injecting malicious JavaScript into a site as the user interacts with it (cross-site scripting), sniffing network traffic in order to intercept HTTP headers (a man-in-the-middle attack), or triggering unintended HTTP requests to the site when they’ve already authenticated (cross-site request forgery). Fortunately, modern browsers implement simple security measures that allow you to protect your session cookies against all three of these techniques. You can enable these security measures simply by adding keywords to the Set-Cookie header returned by the server.

 

Cross-Site Scripting

Attackers often use cross-site scripting to steal session cookies. An attacker will try to use JavaScript injected into a user’s browser to read the user’s cookies and send them to an external web server that the attacker controls. The attacker will then harvest these cookies as they appear in the web server’s log file, and then cut and paste the cookie values into a browser session—or more likely, add them to a script—to perform actions under the hacked user’s session.