Cookies are Bad for You: Improving Security on the Web

*
Accepted Session
Short Form
Scheduled: Thursday, June 23, 2011 from 1:30 – 2:15pm in B202/03

Excerpt

Almost every web application relies on cookies to authenticate each request after the user logs in. Cookies are vulnerable to cross-site request forgery and session hijacking. It is time to explore better, more secure alternatives that are now possible thanks to practical in-browser cryptography.

Description

The release of Firesheep last year and the presentation by Reid Beels and Michael Schwern at the last Open Source Bridge opened the industry’s eyes to the fact that most web applications are inherently insecure. Any application that sends requests over plain HTTP and that uses cookies to track user sessions is vulnerable to session hijacking.

Many applications have reacted to this by offering options to run all traffic through HTTPS. Examples include Gmail, Github, Facebook, and Twitter. Using HTTPS does go a long way in improving web application security. But in most cases HTTPS security is opt-in – probably due to difficulties in rolling out HTTPS on a large scale and added application complexity. This means that only relatively paranoid users benefit. Less fortunate users, like Ashton Kutcher, will often be left vulnerable.

Furthermore, HTTPS by itself does little to protect against cross-site request forgery. It is still necessary for developers to use form tokens, JSON obfuscation, and the like to protect application resources. This results in extra complexity and statefulness.

CSRF does not just force complexity though. Its existence actively stifles innovation. The new cross-origin resource sharing specification, which allows servers to opt-into cross-origin XHR requests, presents many possibilities for rich interaction between web applications. Unfortunately this specification is infrequently used because it opens up XHR as another vector for CSRF attacks in cases where cookie authentication is used. In the eyes of many developers this is just too dangerous to justify exploring a new technology.

All of these problems are products of the fundamental design of cookie authentication: what is essentially a temporary password is transmitted with every web request and that password is easily accessed – directly by eavesdroppers or indirectly by third-party web pages.

There are better options. There are now pure JavaScript implementations of various cryptographic algorithms, including SHA-1, SHA-256, AES, and RSA. There are also well-studied authentication mechanisms built on top of those algorithms designed specifically to prevent man-in-the-middle attacks, like session hijacking. And an authentication mechanism based on JavaScript rather than cookie data would be far less vulnerable to CSRF.

I will explore authentication mechanisms such as HMAC, as seen in OAuth, and block cipher authentication, e.g. CMAC. I will present on the applicability and feasibility of implementing these solutions in JavaScript in ordinary web applications. I will analyze performance and cross-browser compatibility considerations. Finally, I will demonstrate my own recommendation for next-generation browser authentication.

Speaking experience

Speaker