"Sidejacking" has entered the lexicon of network attacks. This newly defined term refers to a method of hijacking an in-progress Web session with a remote service - like Gmail - by intercepting and re-using the credentials that identify you to that server. A sidejacker can read and send email from your Gmail account, update MySpace pages, and potentially steal your identity and make your friends and colleagues think you're evil, insane, or criminal. And that's just for starters.
These credentials can be grabbed without using encryption cracking tools, and often can be intercepted and used even if you logged into a site in a secure manner. Sidejacking doesn't require that a cracker gain remote access to your computer, nor does having session information sidejacked necessarily make your computer more vulnerable. Protecting against sidejacking may take a rethink on the part of Web site operators, users, and browser makers.
Robert Graham, one of the principals of, presented his research at the Black Hat security conference early this month and released a proof-of-concept program shortly thereafter called . He earned kudos by showing sidejacking using live sessions within the room, rather than just a canned demo, showing how he could take control of a Gmail session, and send email from the person's account stating, "I like sheep." (Errata's other principal is , by the way.)
Sidejacking is the jimmy that slides into the small gap between a browser and a server, enabling a cracker to pop the lock. He can't necessarily steal your Internet car, but he can grab the registration without leaving a mark.
Graham's presentation didn't reveal anything about this kind of man-in-the-middle attack that hadn't been talked about before, but he showed the scope of it and provided tools to automate the process. He moved it from a known problem, the severity of which wasn't appreciated, to a serious liability that needs to be addressed urgently.
State Your Name and Password -- Sidejacking works because there's a disconnect between the level of security on most Web-based services (other than banking and truly high-security services) applied to the step in which you provide authentication information - usually a login name or account coupled with a password - and to the session that follows while you're logged in.
This typically isn't an issue on a home network, in which the risk of interception is low or none, and the odds of data being captured between your computer and remote servers by parties other than governments is vanishingly low. The use of public Wi-Fi networks, especially with handheld devices like the iPhone, vastly increases the odds that someone could be monitoring your transmissions over open Wi-Fi networks.
Many webmail and other services require or allow you to log in over an SSL/TLS (Secure Sockets Layer/Transport Layer Security) protected session. SSL/TLS describes a neat dance that ensures you have an encrypted connection between your browser and the server on the other end. (For more about how SSL/TLS works, read Chris Pepper's exhaustive "," 2007-06-25.)
Not all services require an encrypted login, but I strongly recommend that you attempt to use such logins exclusively. You can tell whether a login uses SSL/TLS or not by checking for two characteristics: the URL for the location starts with https rather than http, and a lock icon appears. Some sites include locks in their site design, often near log-in windows or in navigation bars. Those don't mean diddly. If a proper SSL/TLS connection is established, your browser shows a lock icon outside the page area. In Safari, you find the lock in the upper right corner of the window (it's subtle); in Firefox, it's in both the Location field (on the right but within the field) and in the lower right corner of the window.
(Some sites that offer secured logins foolishly present a regular Web page on which you enter data; when you click the login button, the data is sent to a secure page. This makes the login susceptible to hijacking at Wi-Fi hotspots, too, by giving crackers a chance to present a fake login page. Multiple techniques allow a ne'er-do-well to set up a fake hotspot or poison information on an actual hotspot in such a way that they fake the appearance of common banking and ecommerce sites. You can't fake a secured site without a browser prompting you with a warning about a certificate problem, but if you present a fake unsecured page, you can redirect a user to a real login on the secured side while capturing their credentials in the process.)
Here's the tricky part, and why sidejacking works. Once you have proven yourself to the service, and it has pulled up your account details, what happens next? If you're not using a banking or other site that secures the entire session with SSL/TLS, you may be dumped back into an unsecured Web session. It's all about tokens.
Prove Yourself with Tokens -- The Web is, by its nature, stateless. That means that there's no inherent connection from one action to the next as you click through links on a given Web site. Cookies provide a sense of state, enabling a Web site to request that your browser store bits and pieces of information that identify you on each subsequent page view, whether in quick succession or separated by days. Site developers can also require a special kind of Web password that can retain state, too, although it's little used, and I'll explain why in a moment.
What typically happens when you log into a Web site is the following sequence:
After a predetermined period of time, often as little as 30 minutes without activity such as viewing additional pages, the token expires. The Web server may have set the cookie to expire, meaning your browser will delete the cookie on your next visit to the Web site rather than transmitting it; or the server may delete the token from its own database, and reject the one provided by your browser. Or both.
The token can be combined with an IP address to prevent random attempts to generate tokens, although tokens are usually long enough that trillions or quadrillions of possibilities are available.
Since that token is passed in the clear and used consistently throughout a session over a period of time, that leads to sidejacking's modus operandi: replaying (re-using) the same authentication information that a legitimate party uses.
Tokens Lead to Cracks in the Process -- What Graham demonstrated is that these tokens aren't bound up with any specific information about the browser - nor can they be. If you intercept the tokens over an open Wi-Fi link, even a paid Wi-Fi network or one with security that has shared users you don't know, you can replay those tokens in a fashion expected by the service, and create a fully valid session at a Web site.
The reason tokens can't be associated with a given browser or user is that there's no real binding between cookies, information stored in them, the browser, and its environment. It's no use to check whether the cookie came from a certain IP address, because many service providers bind up all outgoing requests through proxy servers or single IP addresses. Browser characteristics - the "user-agent" string - can be faked easily. It's possible that future browsers and servers could include the capability of offering some form of encrypted cookies in unsecured sessions. This binding could rely on SSL/TLS as well, but instead of encrypting an entire session, would protect only the cookies. It would reduce computational load while improving security. Browsers and servers would both require updates to make this happen, and I'm unaware of any such initiative.
To see how hard it is to sidejack a session, I fired up Ferret and Hamster, the two software packages Graham used; Ferret has been out for a while. Using a virtual Windows XP machine under Parallels Desktop, I started capturing data with Ferret. I visited Gmail and some other sites. Then I turned to Hamster, which acts as a Web proxy to present you with captured information. You can also simply enter the Web address for a site for which tokens have been grabbed, and Hamster inserts them as cookies. I logged into my own account at Gmail quite easily via this means.
Running Ferret and Hamster requires a little bit of Windows command-line knowledge, and a small understanding of how cookies and proxies work. Graham didn't intend for these to be polished applications, just workable examples of how easy it is to automate this process.
The weakness here is that the plain bit of text is sent in the clear if not protected by SSL/TLS. So why don't sites just use SSL/TLS or other means to keep you safe? Let's answer that.
Server Load and User Experience Lead to Less Security -- In a draft of this article, I posed the question: Why don't Web sites that rely on tokens just use SSL/TLS for all pages to protect them? Google's Gmail, for instance, offers this as an option. Instead of typing in gmail.com and being redirected to http://mail.google.com/mail/, you can type in  and have a secure experience throughout. Gmail is the exception, though, and doesn't even offer this option by default.
As we often do here at TidBITS, I circulated the draft among a group of experienced Macintosh writers, professionals, and information technology experts, asking them specifically - why isn't there more SSL/TLS? The answer, quite simply, is cost.
Having run secure servers myself, I knew there was an additional load in terms of bandwidth (encryption adds bits for handshaking and other details), latency (encrypted and decrypting adds time on both ends of the link), and computational load (encryption burns processor cycles).
What I didn't know is that the cost isn't, say, 20 percent or 50 percent higher, but could be 1,000 percent higher or more when you are running Web sites of any scale. For a smaller operation, like TidBITS, we might see a tiny incremental cost, or our secured pages might load slightly slower than unsecured ones for the average user.
Once you reach a level where you have tens of thousands or even millions of visitors an hour, however, the scale tends to explode, our colleagues said. Because the number of SSL/TLS transactions per second that a given server can handle is much lower than the number of unsecured transactions - perhaps as few as one-fifth as many! - a moderately busy firm will need to increase the number of its customer-facing servers dramatically to provide the same response time and handle the same number of users.
Typically, the SSL/TLS servers face the customer, and then relay requests for information over plain Web connections within the local network. That, of course, adds complexity, with many different secure servers asking internal servers for information.
A company can, alternatively, add specialized encryption hardware to their servers, speeding up SSL/TLS handling and reducing additional server needs, but that adds more cost and complexity per box, and more points of failure. It might also require more expensive servers if the current boxes lack enough open card slots for the encryption cards.
Either method increases power consumption, and thus operating expenses. And increasing complexity means things are more likely to break, and break for reasons that cannot be reduced to the component parts of failure.
SSL/TLS is also a kind of blunt instrument. If you're not already protecting your behavior and data on open networks, you probably don't care too much about someone seeing the contents of what you're reading or browsing. But you don't want to have your identity stolen or accounts misused. Isn't there a way that doesn't involve SSL/TLS's complexity and cost, but still protects tokens? Yes. And you'll laugh when you find out why it's not being used.
The Method That Works Best Is Avoided -- As I mentioned earlier, there's a special kind of Web password that can be sent in a secure fashion and can maintain state like a token passed via a cookie. HTTP (Hypertext Transfer Protocol) is the standard that defines how Web browsers and servers request and exchange data. HTTP authentication lets a server request a user name and password for entry. There are both basic (unsecured) and "digest" (secured) methods of HTTP authentication. (Digest refers to a form of encryption that lets a sender confirm to a recipient that they both share the same password without revealing that password.)
With, both the Web server and browser can pass the user's identity without the encrypted messages used to define identity being valuable when sniffed. In a well-designed implementation - not all of them are - the browser and server increment a shared number with each request passed so that previous digests can't be replayed by a sniffer storing and later using the digest equivalent of a token.
Now this combines the best of both worlds, right? So why isn't it widely used? Because the presentation of a login dialog box is so darned awful. You've probably encountered an HTTP authentication dialog when you've visited a site that you didn't have access to by accident, or didn't know you needed a password to use. The dialog pops up with some limited information, such as a little text that describes the site you're visiting. It asks for a user name and password, and some browsers offer to store credentials for a subsequent visit.
There's no way to modify the appearance of that dialog box. And any failure to enter the information correctly results in the box appearing again each time you click OK. If you click Cancel, an error page - which can be customized - appears.
Now, it's more or less too late. Unless every browser suddenly supported Web page-based HTTP digest authentication, no site could count on this as a method to log in. So we're stuck with the current system. Let's look at the risks, and then some alternative solutions.
Risks of Sidejacking -- The risks from having a session sidejacked can be quite high. With access to your primary email via a webmail account, a sidejacker could go to various sites that you use and state that he has "forgotten your password." Foolish sites then send your password in email to re-enter, putting it into the hands of the miscreant. Smart sites instead send an email message with a Web link for you to follow to provide additional confirmation details that validate your ability to retrieve the password or set a new one. (You may have noticed that most banking and many ecommerce sites have asked you to provide additional information for this purpose in the last year. It's not a coincidence.)
Smart ecommerce sites won't allow you to change your shipping address or retrieve a stored credit card number without authenticating again, so you're okay there. For instance, Amazon.com requires a new, secured login session whenever you check out, and once re-authenticated, the session is entirely protected by SSL/TLS, hiding the details from local sniffers.
Sidejacking can't extract an Amazon.com password, so it doesn't allow a malefactor to have items shipped to his address at your expense. He could, however, have stuff sent to you via the 1-Click ordering feature. Once logged into 1-Click on a given browser, you stay logged in and require no additional authentication. Amazon warns, in a remote help page, that you shouldn't leave 1-Click enabled after using a "public terminal" (how quaint) to place an order. But sidejacking may cause Amazon to rethink 1-Click's implementation.
Amazon never sends your credit card number back to you in a secured or unsecured session, by the way. Other sites' protections vary widely, but no site accepting credit cards should ever pass the number back. I recall an incident during the brief time I worked at Amazon.com in late 1996 when a well-known technology executive and regular Amazon customer complained that if he entered his credit card incorrectly, he was forced to re-enter it entirely on the subsequent page. Jeff Bezos was adamant that this wasn't a bug - rather, it was a feature. He and the rest of management were far ahead of the curve in worrying about in-transit theft of card numbers.
Sites with less clever developers and managers will be easier for crackers to burst open using the sidejacking wedge. Graham and others have suggested that with the wide use of social networking sites like MySpace, a sidejacker could distribute a viral load to a large audience by having a tool that automated grabbing MySpace tokens, retrieving existing pages, and re-uploading those pages with attacks built in.
Your likelihood of being sidejacked depends entirely on location. If no one ever runs sidejacking software while you're using Wi-Fi in a public location, or if you seldom use public Wi-Fi hotspots, your data (and your identity) are in little danger. But with automated tools and some benefit - identity theft or virus spreading via email - your likelihood shoots way up. Any popular hotspot could become the site of a sidejacking. Adam Engst's take on this from several years ago in "" (2004-04-05), is still a good study.
Protecting Web Sites from the Sidejacker -- How could a Web site alter its behavior to help protect its users from sidejacking? The Web site could require SSL/TLS for all connections. As noted above, this could be expensive, but it's extremely secure. Many systems that involve payment and account management - such as our partner, eSellerate, which handles Take Control book ordering and payment - choose to encrypt everything.
More realistically, a site could chain tokens and monitor for attempts to capture and reuse tokens. Here are my ideas about this, which I'll be implementing in all future designs that maintain state through tokens.
First, a server could chain tokens by providing and updating a new token each time a user requests a page. Tokens could persist only as long as it takes for the newer token to be used. Thus a time-limited token might last for a few pages, but as soon as a new token is generated, the old one expires, significantly reducing the chance of your session being sidejacked. Encouraging a logout to delete a token at the end of a session is a good idea, too. Unless the sidejacker is following your session and constantly changing his token, he'll be locked out. This adds some additional computational load on database servers, but nothing exceptional. It is essentially a poor man's version of HTTP digest authentication, but it could work.
Second, when a token is used by what appears to be a different browser or when expired tokens are consistently used, a user in an active session could be warned. "Hey," you tell them the next time they load a page. "It looks to us like someone is trying to hijack your session. Are you on a public network? You may want to log out now, and resume your session later. In the meantime, here is some security reading." This could result in false positives, but it's one potential strategy.
Ultimately, the Web is still an open means of exchanging data. Unless you use encryption as a means to reinforce identity, identity becomes something that's easily stolen.