WWW 2008 / Refereed Track: Security and Privacy - Web Client Security
April 21-25, 2008 · Beijing, China
SessionLock: Securing Web Sessions against Eavesdropping
Ben Adida
Center for Research on Computation and Society (CRCS), Harvard University Children's Hospital Informatics Program (CHIP), Harvard Medical School Cambridge, MA, USA
ben@eecs.harvard.edu ABSTRACT
Typical web sessions can b e hijacked easily by a network eavesdropp er in attacks that have come to b e designated "sidejacking." The rise of ubiquitous wireless networks, often unprotected at the transp ort layer, has significantly aggravated this problem. While SSL can protect against eavesdropping, its usability disadvantages often make it unsuitable when the data is not considered highly confidential. Most web-based email services, for example, use SSL only on their login page and are thus vulnerable to sidejacking. We prop ose SessionLock, a simple approach to securing web sessions against eavesdropping without extending the use of SSL. SessionLock is easily implemented by web develop ers using only JavaScript and simple server-side logic. Its p erformance impact is negligible, and all ma jor web browsers are supp orted. Interestingly, it is particularly easy to implement on single-page AJAX web applications, e.g. Gmail or Yahoo mail, with approximately 200 lines of JavaScript and 60 lines of server-side verification code. the web was made stateful. Over the years, in order to protect users' security and privacy, the details of cookie handling have b ecome quite intricate, but the basic functionality remains: the server assigns the browser a token, and the browser sends this token back to that sp ecific server on every subsequent request.
Web sessions are vulnerable to eavesdropping. A static token sent over a plaintext channel is obviously insecure: a network eavesdropp er can easily read this token and replay it to tap into the victim's session, effectively imp ersonating the user for the length of the session. Interestingly, web sessions have not evolved much since the first days of web cookies: they remain quite vulnerable to eavesdropping. Wi-fi networks make things worse. Wireless ("wi-fi") networks are now ubiquitous. Though wireless standards provide for password-based access-control and transp ort-layer encryption, wireless base stations found in hotels, conference lobbies, coffee shops, and airp orts are configured without this level of protection. Users connect freely to the wireless base station, and only then are asked to provide login credentials. This approach allows wireless op erators to manage p er-user password-based access control, rather than a single password for the wireless base station. In this setting, eavesdropping on HTTP traffic and stealing web session tokens is so easy that it has recently received a new name: "sidejacking" [9]. Numerous common web applications, including most online webmail providers, are vulnerable to these trivial eavesdropping attacks. SSL is not for everyone. One way to prevent eavesdropping is to use SSL to encrypt all web traffic. This approach is employed by financial institutions that cannot afford to have their clients' web sessions hijacked so trivially (or their customers' financial data read as easily as sniffing the network). When traffic is encrypted, an eavesdropp er is p owerless. Unfortunately, delivering a web application over SSL triggers numerous complications. Even with significant serverside computational p ower, SSL's caching b ehavior, its need to download a complete resource and verify it b efore displaying any part of it, and its all-or-nothing nature result in a significantly more "sluggish" exp erience for the user. Services like Gmail, Yahoo, Hotmail, Faceb ook could easily afford to deploy SSL: all of them use SSL to secure users' password at login time, acceleration hardware for SSL makes the server-side computational overhead quite manageable, and Gmail happily lets adventurous users access their mail
Categories and Subject Descriptors
K.6.5 [Management of Computing and Information Systems]: Security and Protection--Authentication
General Terms
Design, Human Factors, Security
1.
INTRODUCTION
The core comp onent of the World Wide Web, HTTP [6], b egan its life as a stateless protocol: the page's HTML and all images were each downloaded using a new HTTP request made over its own TCP/IP connection. To provide a p ersonalized user exp erience, early web "sessions" were implemented using tokens inserted into individual URLs, so that every click would send this session token back to the server. The tediousness of this approach and the fact that a new browser window would not automatically inherit this token made web sessions fairly unreliable. In 1995, Netscap e introduced cookies, small chunks of data that a web server can assign to a browser using HTTP return headers, which the browser is exp ected to send back to the server on every subsequent request. Using cookies,
Copyright is held by the International World Wide Web Conference Committee (IW3C2). Distribution of these papers is limited to classroom use, and personal use by others. WWW 2008, April 2125, 2008, Beijing, China. ACM 978-1-60558-085-2/08/04.
517
WWW 2008 / Refereed Track: Security and Privacy - Web Client Security
at https://google.com/mail/. However, likely b ecause of the usability issues describ ed ab ove, all have chosen to deliver the bulk of their features over plain HTTP, leaving session tokens available for any eavesdropp er to hijack.
April 21-25, 2008 · Beijing, China
Better security without SSL. We propose SessionLock, a
method to improve the security of plain HTTP sessions. We use SSL in exactly the same way that Gmail, Yahoo, Hotmail, and Faceb ook already do: only to set up the session. In addition to the session identifier, we generate a session secret which is never sent over plain HTTP. This session secret is used by the browser to generate an authentication code for every HTTP request. The secret is passed from the HTTPS login page to the HTTP p ortion of the site, and from one page to another under HTTP, by way of the URL fragment identifier. Thus, although all URLs after login are requested over HTTP, the secret is never sent in plaintext over the network. Details are shown in Figure 1. With SessionLock, the prop erties of HTTP, including progressive rendering of images and efficient caching, are preserved. With only private-data-containing URLs affected, images, scripts, stylesheets can all b e delivered over HTTP without additional overhead, exactly as they are delivered today without SessionLock. We implemented SessionLock using only a small JavaScript library and a simple server-side filter on protected requests. No browser add-on is required, and all ma jor modern browsers are supp orted: web applications like Gmail can deploy this solution immediately, with very little code, and no action (or even awareness) required of their users.
every request, so that the server can identity each HTTP request more precisely. The earliest solution to this problem required the server to dynamically emb ed this unique token in every URL of every HTML page. A numb er of web development frameworks still offer a way to automate this URL-token emb edding. Since Netscap e 1.1 in 1995, web browsers supp ort cookies, which allow a web server to send, in an HTTP resp onse, a sp ecial header: Set-Cookie: session_id=8b3xdvdf3jg; This header can also sp ecify a numb er of additional fields, including: · an expiration date, · a secure flag, indicating whether this cookie should only b e sent back over SSL, · the domain, so that foo.example.com and example.com can share cookies if they so choose, · the path, so that different sections of a site, e.g. /foo/* and /bar/* can have different cookies. On every subsequent request, the web client will include all the p ertinent name-value pairs it has received from that sp ecific server. The security of these data is highly dep endent on the transp ort layer: cookies sent over HTTP are easily accessible to a network eavesdropp er.
2.2 Digest Authentication
HTTP offers protocol-level authentication, including the particularly interesting digest mode [7], which all modern browsers now supp ort. In digest auth, just like in plain auth, the web browser provides a distinct user interface to prompt the user for her username and password. Unlike in plain auth, digest auth provides a challenge-resp onse mechanism for sending along the password, which ensures that a network eavesdropp er cannot extract the password. Web services could use digest auth as a way to secure sessions against eavesdropping. Unfortunately, HTTP-based authentication has b een shunned by most web services for a numb er of reasons [18]: 1. The HTTP-password-entry user interface cannot b e customized or integrated into a more complete form, making it difficult for users to proceed if they've forgotten their password or want to register a new account. 2. On the server side, authentication is handled by the HTTP stack which must have direct access to a username/password database, since it needs to handle the challenge-resp onse b efore handing over processing to the application code. 3. The server cannot easily trigger a logout, for example after some p eriod of inactivity. As a result, HTTP authentication, even in digest mode, is not likely to provide a deployable defense against eavesdropping.
Getting Closer to User Intuition. It is relatively intuitive for average users to understand that unencrypted wireless traffic can b e "overheard": browsing over HTTP at a conference is a bit like having a private phone conversation on a crowded bus, where your neighb ors might easily catch snipp ets. Session hijacking, on the other hand, is quite unintuitive: after all, login pages are usually served using SSL, the padlock icon is visible in the browser, and the average user would b e justified in thinking that her session is safe from attackers. One goal of SessionLock is to make sure that reality matches this intuition more closely: having one's HTTP traffic overheard is still a concern, but having one's session hijacked is not.
1.1 This Paper
In Section 2, we review the current approaches that web develop ers can take to secure their users' sessions. In Section 3, we consider the simple SessionLock building blocks, and in Section 4 we describ e SessionLock in detail. In Section 5, we consider some immediate extensions to the basic scheme. We evaluate implementation and p erformance issues in Section 6, highlight a numb er of p oints for discussion in Section 7, and review related work in Section 8.
2.
CURRENT PRACTICES
Though techniques for maintaining web sessions have evolved since the early days of the Web, they have remained surprisingly stable.
2.3 Locking Sessions to IP Address
One natural reaction to the eavesdropping problem is to bind web sessions to the user's IP address at the time of session initiation: if a session token is received from a different IP address, the web server can prompt the user to
2.1 Web Sessions
Maintaining web session state requires having the web client provide some unique identifier to the web server on
518
WWW 2008 / Refereed Track: Security and Privacy - Web Client Security
April 21-25, 2008 · Beijing, China
Figure 1: The SessionLock Protocol: An initial SSL exchange sets up the session secret, which is passed from HTTPS to HTTP, and then from one HTTP page to the next, using the fragment identifier. Note how the use of the fragment identifier effectively creates a client-only channel from one page to the next. Each HTTP request is then timestamped and HMAC'ed with this secret for authentication. SSL portions are noted in green. The secure cookie stays around in case the secret needs to be recovered and resent into the HTTP realm (a process not represented here.) re-authenticate. Unfortunately, esp ecially in our imp ortant wi-fi use case, many users surf the web b ehind a Network Address Translator so that many users are effectively using the same IP address. In our sp ecific use case, the attacker on the same wi-fi network is, by default, already using the same external IP address as the victim. From the p oint of view of the server, if an attacker can steal a victim's cookie b ehind a network router, there is no detectable difference b etween the victim and the attacker, and IP-address-binding is useless. cally prohibits the use of latency-reducing, geography-based caching by content-delivery networks. In addition, web browsers b ehave differently under SSL. Resources are not cached nearly as well or as often, increasing the average page load time over the course of a web session. Resources cannot b e displayed until they are fully loaded and their signature verified, preventing progressive loading and generally making the application feel more sluggish than the identical site over plain HTTP. As a result of these complications, esp ecially those which raw server computational p ower cannot address, a numb er of common web services are delivered over plain HTTP, with only the login page processed using SSL to protect the password. Interestingly, even if SSL is offered as an option, the existence of a service over plain HTTP is sufficient to exploit the weakness with a minor social engineering attack that surreptitiously tricks the user into visiting the plain HTTP URL, thereby leaking the cookie into an insecure network 2 .
2.4 SSL
SSL provides end-to-end encryption b etween the web server and browser, clearly foiling passive eavesdropp ers. Unfortunately, SSL requires more work on the server side and, more imp ortantly, triggers a numb er of sub-optimal b ehaviors on the client side. An SSL server must run on its own IP address (no virtual hosting), b ecause the SSL certificate handshake occurs b efore the browser is able to sp ecify a virtual hostname [2] 1 . In addition, an SSL server must deliver all resources, including static graphical layout elements that typically require no protection, under computationally intensive SSL in order to prevent browser warnings ab out mixed content. This typiServer Name Indication (SNI), a TLS extension [4], provides supp ort for virtually hosted secure web sites, but not all browsers and servers supp ort it yet.
1
3. BUILDING BLOCKS
We now cover the SessionLock building blocks. We note that the technical comp onents are particularly simple and require only a cursory explanation.
2
http://seclists.org/bugtraq/2007/Aug/0070.html
519
WWW 2008 / Refereed Track: Security and Privacy - Web Client Security
April 21-25, 2008 · Beijing, China
3.1 Fragment Identifier
The URL sp ecification [3] defines the fragment identifier, the p ortion of the URL that follows the # character. As its name implies, the fragment identifier designates a p ortion of the resource. For example, consider the following URL: http://host/rest/of/url#paragraph4 Here, #paragraph4 is the fragment identifier. When the primary resource, in this case http://host/rest/of/url, is an HTML document, the fragment identifier tells the browser to scroll the viewp ort to the section of the document that reads: ...
When no such p ortion of the document exists, the browser doesn't scroll, and the fragment identifier remains in the URL, unused. The fragment identifier is never sent over the network: the browser requests the full resource and uses the fragment identifier to scroll. In other words, the web server is never aware of the fragment identifier to which a user navigates: a user can click from one fragment to another within a page, with his browser scrolling automatically to the appropriate location, never p erforming any additional network request. Though it is never sent over the network, the fragment identifier does app ear in the browser's URL bar. As a result, it is accessible to JavaScript code running within the page using the command document.location.hash.
2. The web browser uses this secret token to authenticate, using HMAC, every subsequent, time-stamp ed plain HTTP request it makes. 3. The session token is never sent over the network in the clear: it is communicated from the SSL login page to the first plain HTTP page, and to each subsequent plain HTTP page thereafter, using the URL fragment identifier. 4. An attacker limited to eavesdropping capabilities never sees the session secret and cannot generate valid HTTP requests on b ehalf of another user's session, other than the ones it intercepts. We now provide additional detail for the ab ove outline.
4.1 Generating the Secret Token
Alice visits her webmail site, example.com. She is directed to a login page over SSL, where she enters her username and password. The server sets up her session, sets a nonSSL session_id cookie, then an SSL-only cookie session_ secret, and redirects Alice to http://example.com/login/done#[session_secret] Because this redirect command is sent to Alice's browser over SSL, its content is secure against eavesdropping. Then, when Alice's browser loads the new, non-SSL URL, the session_secret remains secure from eavesdropping, b ecause it is located inside the fragment identifier and thus not sent over the network.
3.2 Authenticating Web Requests with HMAC
Simple message authentication b etween two parties with a shared secret is easily achievable using a Message Authentication Code (MAC) [16] algorithm. In particular, HMAC [10] is a hash-function-based message authentication technique which is easily implemented and quite efficient in just ab out any programming environment, including browser-based JavaScript. A numb er of web-based APIs, including Google APIs 3 and the Faceb ook Platform 4 already use HMAC for authenticating requests. Typically, web clients and the web service share a secret. When making an HTTP request, the client prepares the entire request including all parameters and a timestamp, HMACs the full request string using the shared secret, and app ends to the request an additional HTTP parameter whose value is the resulting HMAC. The server verifies the timestamp and re-computes the exp ected HMAC on the rest of the parameters (minus the HMAC parameter itself ), checking it against the HMAC submitted by the client. Though the same result could b e accomplished using digital signatures, HMAC is easier to set up b etween two parties that share, during some setup phase, a secure channel, and it is generally far more efficient.
4.2 Keeping the Session Secret Around
To keep the session_secret around from one page to another, it must b e app ended as a fragment identifier to every URL the user navigates within the web application. Imp ortantly, this cannot b e done on the server side, as it would then b e available to the eavesdropp er when the HTML is transferred over plain, unencrypted HTTP. The app ending of the session secret can only b e done on the client side using JavaScript. Thus, up on page load, SessionLock JavaScript code traverses the page, app ending the fragment identifier to every clickable link and every form target. Interestingly, in the case of AJAX applications [8], where requests are made in the background without clearing the page's JavaScript scop e, it is not necessary to app end the session secret to URLs after the first page has loaded, b ecause this first page and its JavaScript scop e stay put. In other words, it is easier to use SessionLock with an AJAX application than with more typical page-to-page web navigation.
4.3 Timestamping and HMAC
With the session secret in JavaScript scop e, we must then ensure that every HTTP request is augmented with an HMAC. For clickable links and form submissions, a JavaScript event handler intercepts the user request, app ends a timestamp parameter, generates the HMAC on the entire request line, and adds a second parameter with this HMAC as its value. Once these modifications are done, the event proceeds as initially requested, only with two new parameters that authenticate the request to the server. For AJAX requests, JavaScript can intercept all calls to XMLHttpRequest to achieve exactly the same task. In this
4.
THE SESSIONLOCK PROTOCOL
1. At login time over SSL, the web server delivers a session secret to the web browser.
At a high level, SessionLock functions as follows:
3 4
http://code.google.com/more/ http://developer.facebook.com
520
WWW 2008 / Refereed Track: Security and Privacy - Web Client Security
case, the additional parameters are not even reflected in the URL bar, making SessionLock even more transparent. Once again, it app ears that SessionLock is easier to implement with AJAX applications.
April 21-25, 2008 · Beijing, China
5.2 Local Browser Storage
The latest versions of Internet Explorer and Firefox, which together cover ab out 95% of web users 5 , b oth offer simple mechanisms for client-side data storage that is never automatically sent over the network, resp ectively window. userData and window.globalStorage. In addition, the upcoming HTML5 sp ecification [11] standardizes this JavaScript API for client-side, domain-sp ecific data storage along the lines of Firefox's implementation. Safari, the third largest browser, is exp ected to implement this API, making clientside storage a virtual certainty in the near future. In HTML5, the following JavaScript code stores data: globalStorage[`example.com'].session_key = `8xk3jsldf'; which can later b e retrieved by another page from the same domain using the following code: do_stuff_with_key( globalStorage[`example.com'].session_key );
4.4 Recovering From Failure
Because of our ad-hoc approach to communicating the session secret from one page to another, it is conceivable that the session secret will b e lost. The user might typ e in a URL manually, click a b ookmark, or otherwise access the service without the session secret in the fragment identifier. To force the user to re-login at this p oint would break existing exp ectations for web services. Fortunately, it is easy to recover the session secret, using an IFRAME that accesses a small SSL page that minimally affects the user exp erience. The web page, noticing that it does not have a session secret, op ens up an invisible IFRAME with the SSL URL https://example.com/login/ recover. The document in the IFRAME is tiny: (This code assumes the existence of a get_secret() function, which can b e implemented in a few lines of code that p erforms a regular expression match on document.cookie.) This code, which runs in the SSL scop e, simply recovers the session secret from the SSL-only cookie, then redirects the browser to the plain HTTP p ortion of the site with the secret in the fragment identifier. This plain HTTP page, loaded within the IFRAME, can access the secret using document.location.hash. Then, since it is now in the same scop e as the containing page, it can make a simple procedure call to the parent frame to deliver the token and close the IFRAME. This recovery protocol is diagrammed in Figure 2.
5.
EXTENSIONS
Local browser storage cannot solve everything on its own: it cannot b e used to transfer the session secret from the HTTPS session-setup URL to the HTTP p ost-login URL, b ecause those two URLs are of different origins, and clientside data stored while at an SSL URL cannot b e read by JavaScript from a non-SSL URL, even if they share the same domain. However, once the token is transferred to HTTP using the SessionLock fragment identifier approach, it can b e stored in local session storage so that, even if a user subsequently loses the secret token by deleting the fragment or op ening up a new browser window, the JavaScript code can easily recover it with simple API call, instead of an IFRAME and additional network access. Augmented with local browser storage, the overhead of SessionLock b ecomes quite negligible, even in edge cases.
The basic SessionLock protocol can b e extended to supp ort alternate use cases.
5.3 No SSL Whatsoever
We can implement SessionLock without any SSL, even on the login page. On session setup the following steps are taken: 1. the server assigns the browser a session cookie. 2. the client-side JavaScript code initiates a Diffie-Hellman key-exchange [5] with the server, effectively generating a shared secret b etween the browser JavaScript scop e and the server. 3. this shared secret b ecomes the HMAC key used in the SessionLock protocol, with the server storing the secret in a server-side session, and the browser passing on the secret from one page to the next using either the fragment identifier or the local-browser storage as explained ab ove.
5.1 Optimizing Link Setup
The SessionLock JavaScript that traverses the DOM to add appropriate event handlers is likely one the weakest pieces of the puzzle, where some links may b e missed and the time taken to traverse a complicated HTML DOM may b e onerous. If the web application is built with SessionLock in mind, then this click handler can b e added explicitly in the HTML, only on the links that explicitly need authentication: next page
This approach will increase the size of the HTML a bit 4. if the browser loses its secret, it can re-p erform a Diffiewhile sp eeding up the JavaScript execution significantly, since Hellman key exchange with the server, using a numb er no SessionLock code is executed until the user clicks a links, of XMLHttpRequest calls. and even then only a small amount. In addition, with application5 level involvement, only links that require authentication will http://en.wikipedia.org/wiki/Usage_share_of_web_ browsers, last visited on February 3rd 2007. b e patched.
521
WWW 2008 / Refereed Track: Security and Privacy - Web Client Security
April 21-25, 2008 · Beijing, China
Figure 2: If the secure token is lost for any reason (1), it can be recovered from the HTTPS cookie using a dynamically generated IFRAME (2), which looks up the cookie and redirects the IFRAME to a non-SSL URL with the token in the fragment identifier (3), which can then pass the token back up to the calling frame (4). In a production implementation, the IFRAME would be made invisible since the it requires no user interaction. The no-SSL approach is clearly less efficient at recovering from a token loss, since a token loss requires the complete re-generation of a new token, rather than the SSL-based retrieval of the existing token. This indicates that the no-SSL approach probably shouldn't b e used unless the browser supp orts local storage, which significantly curtails the chance of this token loss.
6.
EVALUATION
We built a SessionLock prototyp e, available for demonstration and full source code download in the near future at: http://ben.adida.net/projects/sessionlock/ In this section, we review interesting details of our implementation and the associated p erformance of our prototyp e.
Hardware and Connectivity. We used a typical sharedhosting provider, using a small p ortion of a quad-processor Intel Xeon 3.2Ghz server with 4GB of RAM, located in Houston, Texas. We tested Firefox 2.0.1, Safari 2.0.3, and Op era 9 on a Macintosh Powerb ook G4 running at 1.5Ghz with 1.5 GB of RAM. We tested Internet Explorer 6 and 7 on Windows XP Professional running on a 1.8Ghz Intel Core Duo with 1 GB of RAM. Both client PCs were connected via a Comcast home broadband connection in Mountain View, California.
6.2 HMAC Performance
We evaluated client- and server-side computational needs for p erforming HMACs. We determined that, on the slowest browser (Safari) using the sp ecified Mac laptop, an HMAC op eration requires just under 50ms. As this is entirely clientside computation, it is negligible and barely noticeable to the user. On the server side, in Python, one HMAC op eration took 300µs on our setup, a modest computational requirement compared to the average database query.
6.1 Implementation Details
We use a JavaScript library [13] that implements HMACSHA1. Note that, while SHA1 has recently b een shown to have certain weaknesses [19], its security in an HMAC setting has not b een compromised. If it were to b e compromised, a move to SHA256 would b e fairly straight-forward and only slightly more computationally intensive. In addition, we use a JavaScript library 6 that implements robust URL parsing, so that we can dynamically insert the SessionLock parameters into any URL, no matter how complex. Then, our custom SessionLock JavaScript library implements: · detection and parsing of the secret token in the fragment identifier, · recovery of the secure token using an invisible IFRAME, · timestamp-and-HMAC patches for links and forms, · XMLHttpRequest interception for timestamping and HMAC. · automatic traversal of the Document Ob ject Model (DOM) to add event handlers to hook up the linkand-form patching.
6
6.3 Link Patching Performance
We tested the link-and-form patching overhead on a page with 100 links and 10 forms, and found that the worst browser p erformance for page setup on the client hardware sp ecified ab ove required no more than 25ms. We note that the p erformance overhead on a single-page AJAX application is negligible: only one 15-line function definition is required, no matter how large the page.
6.4 Code Overhead
Our SessionLock-sp ecific JavaScript library is 200 lines of code with copious comments, b efore any JavaScript minimization. The JavaScript HMAC and URI parsing code together take up less than 7K of code b efore minimization. On the server side, which we implemented in Python, the login logic required approximately 20 lines of code, and the verification logic ab out 40 lines of code.
7. DISCUSSION 7.1 Security Model
In this work, we explicitly exclude man-in-the-middle attacks, where the attacker either controls IP routing or DNS,
http://stevenlevithan.com
522
WWW 2008 / Refereed Track: Security and Privacy - Web Client Security
e.g. malicious base stations and routers, DNS p oisoning, etc. We assume the attacker can eavesdrop on all network traffic. We do not consider the strength of SSL encryption: our attacker focuses on plaintext traffic and considers encrypted traffic "unbreakable." Thus, we assume that anything a user browses over plain HTTP can b e read by the attacker: if a user is reading their web-based email, the emails she reads are available to the attacker. With SessionLock, our security exp ectation is that the user cannot b e imp ersonated by the attacker: data not read by the user cannot b e read by the attacker, and actions not taken by the user cannot b e taken by the attacker on her b ehalf. We also consider a slightly stronger attacker who, using social engineering techniques, can trick the user into visiting a particular URL. This may b e done using a phishing-like email or instant message. In particular, it is not enough to rely on a user visiting the SSL version of a site if an attacker can trick him into visiting an equally functional plain HTTP version of the same site (without SessionLock protection.)
April 21-25, 2008 · Beijing, China
have expired. In this case, the web server will notice an expired session cookie even b efore it checks the timestamp and HMAC, and will redirect the user to a login page, which should easily allow the user to log in, create a new session, a new session secret, and a redirect to a newly timestamp ed and HMACed version of the b ookmarked page.
Sending to a friend, social bookmarking. If a user sends a SessionLock-augmented link to a friend via email, or esp ecially if she p osts it to a social b ookmarking site, she runs the risk of revealing her session secret. If a recipient of this session secret is also on the same local network and can find her plain HTTP session_id cookie, the user's session may b e fully compromised. Although it is unlikely that a user would p ost a protected link to a social b ookmarking site, this issue merits further careful consideration.
7.3 Deployability
Simple web sites are easily upgraded to SessionLock using our existing JavaScript toolkit that dynamically traverses and appropriately up dates links, forms, and AJAX calls. For more complicated web sites, building from the start with SessionLock in mind is relatively straight-forward: using simple abstraction layers can enable the easy patching of links, forms, and AJAX calls, even when they use custom event handlers. Upgrading an existing, complex web site is a bit trickier and may require a bit of re-factoring: forms and links with existing onsubmit or onclick event handlers are particularly difficult to patch generically, and will, in most cases, require manual patching. There is one interesting exception to this rule for "legacy" web applications: AJAX-only applications that function entirely within one URL, sometimes called "single-page applications" are particularly easy to patch for SessionLock, assuming they use XMLHttpRequest relatively consistently. In particular, sites like Gmail 7 should b e quite easy to upgrade to SessionLock: no HTML forms or links need to b e up dated, thus no DOM traversal is ever required. A single patch to the AJAX handler suffices.
7.2 Effects of typical web user behavior
With the session secret now a necessary p ortion of navigation, we must consider the side-effects of carrying this secret as a fragment within every page. In particular, we consider web page reload, b ookmarking, and sharing with a friend by copy-and-paste or by p osting to a social b ookmarking service. We note that these situations should happ en rarely on sites that require SessionLock, since the pages that are protected by SessionLock are typically not ones that will b e b ookmarked or shared with friends. However, it is imp ortant to b egin to understand how these edge conditions might b e handled, even if we don't handle them fully yet in our prototyp e. We note, again, that none of these p otential complications affect AJAX single-page applications like Gmail.
Page Reload. Page reload is explicitly supported by SessionLock: the token stays in the URL as a fragment identifier, and an onload JavaScript event handler captures it on reload exactly the way it was captured on first load. However, if a user waits too long on a page that contains a SessionLock timestamp, it may b e out of date and fail prop er authentication. In this case, a SessionLock web server returns a JavaScript page that locally recreates a freshly timestamp ed version of the same URL, then uses document.location. replace to reload the page with the appropriate authentication. One exception remains: reloading the result of a POSTed form after the timestamp has expired is recoverable only if the user is prompted to manually resubmit the form. This can b e accomplished using a JavaScript-triggered click of the back button: history.go(- 1); Bookmarking. Bookmarking a page that uses SessionLock will include the timestamp and HMAC at the time of the b ookmarking action. When the page is later reloaded, it is almost certain that the timestamp will b e outdated. In this case, the SessionLock server can b ehave exactly as in the page-reload case, issuing JavaScript code that, within the browser, generates a freshly timestamp ed and HMAC'ed U R L. That said, when a b ookmarked page is loaded, the original session from which that page was b ookmarked is likely to
7.4 Limitations
SessionLock suffers from two imp ortant limitations that should b e carefully noted.
JavaScript Required. SessionLock is entirely dependent on JavaScript: it simply cannot work without. Thus, SessionLock should b e reserved for web applications that already require JavaScript. No Defense Against Active Attacks. SessionLock does not protect against active network attacks. An active attacker can trivially inject code in a plain HTTP URL, steal the session secret and hijack the session. We make no attempt to "fix" this issue in this work: we are solely trying to address the "sidejacking" attack, which is far too easy to launch without leaving a trace.
7
http://gmail.com
523
WWW 2008 / Refereed Track: Security and Privacy - Web Client Security
April 21-25, 2008 · Beijing, China
8.
RELATED WORK
JavaScript Use of the Fragment Identifier. The fragment identifier has b een usurp ed in other ways, usually as a mechanism to maintain state in a single-page JavaScript web application. S5 [17], an HTML slide presentation tool, uses the fragment identifier to indicate which slide to display, with the whole slideshow contained in a single HTML file. The Do jo JavaScript toolkit [14] and other JavaScript libraries use the fragment identifier to enable the normal forward and back buttons in an AJAX [8] web application without full page reloads. The first use of a fragment identifier for security purp oses that we know of is BeamAuth [1], where a b ookmark including a secret token in the fragment identifier is used to defend against phishing attacks for web authentication. BeamAuth and SessionLock b oth use the fragment identifier but can b e made to work together, since they use the fragment identifier at very different times. Security in the Web Application Layer. Others have prop osed security protocols that make use of existing browser features in novel ways, effectively building security into the web application layer. Juels et al. [15] prop ose to use "cache cookies" for security: the browser cache stores secret tokens for two-channel authentication at secure sites, e.g. online banking. Jackson and Wang [12] explore various existing browser features to enable secure cross-domain communication for web mashups. BeamAuth [1] provides some defense against phishing using only existing web features.
9.
CONCLUSION
Using the existing HTTP fragment identifier feature to create a secure, client-side channel b etween HTTPS and HTTP, we have designed and implemented SessionLock, a way to protect plain HTTP sessions from eavesdropping. We b elieve our prop osal is relatively easy to implement, esp ecially in the case of heavily AJAX-enabled applications such as Gmail. In fact, it app ears that Gmail HTTP sessions can b e secured with minimal web-application-level code and negligible p erformance overhead. We note the app eal of solutions, like SessionLock, which use only web-application-level modifications: they can b e deployed immediately by web develop ers. We hop e that exploration of improved security features using only the existing Web stack will b e informative to the improvement of the web browser as an extensible platform for security.
10. REFERENCES
[1] Ben Adida. BeamAuth: Two-Factor Web Authentication with a Bookmark. In Fourteenth ACM Conference on Computer and Communications Security (CCS 2007), Novemb er 2007. [2] Apache Software Foundation. SSL/TLS Strong Encryption FAQ Apache HTTP Server. http://httpd.apache.org/docs/2.0/ssl/ssl_faq. html#vhosts2 last viewed on 1 Novemb er 2007. [3] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifier (URI): General Syntax, January 2005. http://www.ietf.org/rfc/rfc3986.txt.
[4] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, and T. Wright. Transp ort Layer Security (TLS) Extensions. http://www.ietf.org/rfc/rfc3546.txt. [5] Whitfield Diffie and Martin E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, IT-22(6):644654, 1976. [6] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hyp ertext Transp ort Protocol HTTP/1.1, 1999. http://www.ietf.org/rfc/rfc2616.txt. [7] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart. HTTP Authentication: Basic and Digest Access Authentication, June 1999. http://www.ietf.org/rfc/rfc2617.txt. [8] Jesse James Garrett. Ajax: A New Approach to Web Applications, February 2005. http://www.adaptivepath.com/publications/ essays/archives/000385.php. [9] Rob ert Graham. Sidejacking with Hamster, August 2007. http://erratasec.blogspot.com/2007/08/ sidejacking- with- hamster_05.html. [10] R. Canetti H. Krawczyk, M. Bellare. Hmac: Keyed-hashing for message authentication, February 1997. http://tools.ietf.org/html/rfc2104. [11] Ian Hickson and David Hyatt. Html 5. http://www.w3.org/html/wg/html5/. [12] Collin Jackson and Helen Wang. Subspace: Secure Cross-Domain Communication for Web Mashups. In Proceedings of the 16th international conference on World Wide Web (WWW 2007), Banff, Canada, 2007. [13] Paul Johnston. A JavaScript implementation of the Secure Hash Algorithm. http://pajhome.org.uk/crypt/md5. [14] JotSp ot. Do joDotBook. http://manual.dojotoolkit. org/WikiHome/DojoDotBook/Book0. [15] Ari Juels, Markus Jakobsson, and Tom N. Jagatic. Cache cookies for browser authentication (extended abstract). In S&P, pages 301305. IEEE Computer Society, 2006. [16] Message Authentication Code. http://en.wikipedia. org/wiki/Message_authentication_code. [17] Eric A. Meyer. S5: A Simple Standards-Based Slide Show System. http://meyerweb.com/eric/tools/s5/, last viewed on Octob er 26th, 2006. [18] Bill Venners. HTTP Authentication Woes, April 2006. http://www.artima.com/weblogs/viewpost.jsp? thread=155252, last visited on Octob er 31st 2007. [19] Xiaoyun Wang, Yiqun Lisa Yin, and Hongb o Yu. Finding Collisions in the Full SHA-1. In Victor Shoup, editor, CRYPTO, volume 3621 of Lecture Notes in Computer Science, pages 1736. Springer, 2005.
524