HTTP cookies, or how not to design protocols

http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html

by tptacek • 16 years ago

142 48 16 years ago

lcamtuf.blogspot.com

Udo3• 16 years ago

That's a nice summary!

I still think allowing cookies to span more than one distinct domain was a mistake. If we had avoided that in the beginning, cookie scope implementations would be dead simple and not much functionality would be lost on the server side. Also, JavaScript cookie manipulation is something we could easily lose for the benefit of every user, web developer and server admin. I postulate there are very few legitimate uses for document.cookie

tptacek17• 16 years ago

There may be few legitimate uses for document.cookie, but eliminating it does very little to prevent cross-site scripting.

pak2• 16 years ago

How about double-posting session ID's from the cookie within AJAX requests to prevent XSRF? I've certainly used document.cookie for that.

The only other scheme I know of to defend against XSRF is to generate secret values for every request, which is not always practical.

tptacek17• 16 years ago

I'm not sure I can think of one web app I've tested this year that overloaded the session cookie for an XSRF token; it is straightforward to just generate a random token and embed it in the page, and that also gives you fine-grained control over CSRF protection for forms where you want per-render instead of per-session protection.

You don't need to generate per-request tokens unless you want to; the token is simply yet another thing you stick into the session store and splash out onto the rendered page.

(Also, as my colleague Cory points out: if an attacker can influence the ACTION attribute of the form in any way, you've just coughed up your session token to an attacker in the name of blocking CSRF; is the risk worth the reward?).

mike-cardwell4• 16 years ago

You can use the HttpOnly flag with a cookie to prevent JavaScript being able to access it. Here's a good summary:

http://www.owasp.org/index.php/HttpOnly

If you are serving a cookie, and JavaScript doesn't need to be able to access it, you should set it to be HttpOnly to try and reduce the effects of an XSS.

tptacek17• 16 years ago

It doesn't seem like Michal is sold on HttpOnly and I definitely am not either; most everything you can do with a stolen cookie, you can also do quickly and silently using a captive browser during an XSS attack.

kls4• 16 years ago

Also, JavaScript cookie manipulation is something we could easily lose for the benefit of every user, web developer and server admin

With more and more apps moving to pure JS / CSS/ and HTML front ends the lack of being able to manipulate cookies would kill a good deal of in app storage abilities. Eliminating useful feature to make someone else's job easier is rarely ever a good solution.

dansingerman• 16 years ago

Would using javascript's same origin policy have solved 90% of the issues?

On the face of it that seems the case.

clark• 16 years ago

In my opinion, session cookies are primarily used as a work around since HTTP Authentication is incredibly ugly. Perhaps if that core problem was addressed, the need for cookies would be dramatically reduced.

psadauskas3• 16 years ago

I've never understood whats so "ugly" about http authentication. Digest auth can get a little verbose, to be sure, but Basic+SSL is simple, and both are far easier than roll-your-own Cookie auth. In fact, the way most people & frameworks implement cookie auth sessions are no less secure than Basic auth. Haven't the events of the past week demonstrated we should all be using SSL anyways, in which case Basic auth would be fine for everyone.

tptacek17• 16 years ago

Basic auth is only simpler than cookie auth if you (a) aren't using a modern web stack (ie, you aren't using ASP.NET, J2EE, Rails, Django, &c) and (b) have only a few users.

If either (a) or (b) do not hold, Basic Auth is at least as hard as cookie auth.

ataggart• 16 years ago

A few problems with basic auth:

    * Browser specific UI, which leads to:

      * No place to put password recovery links

      * No place to put explanatory text

    * No mechanism for logout

tptacek17• 16 years ago

HTTP Authentication is dead and is never coming back. Leave aside all protocol design elegance arguments and think about the situation for app developers; form auth is simply better:

* It has a simple reliable log-out button.

* It gives app developers more reliable fine-grained control over the login process because it in no way relies on browser chrome.

* It better supports advanced security and UX idioms, like signup-or-register or SMS-me-a-one-time-login.

* Virtually every web app in the world needs a session-keyed store anyways, and authentication is the easiest of the AAA problems anyhow, so building that one tiny piece into the protocol doesn't solve any problems.

* [ps]

Doubtless there are a myriad of nitpicky arguments about how HTTP Auth can be massaged to mitigate these problems, but who cares? Cookie auth works for everyone. Basic auth manifestly does not. Why would anyone want to expend major effort to take an archaic protocol and make it asymptotically as good as what every web app stack already provides?

[ps]: Cookie auth schemes can also be extended without getting Microsoft, Mozilla, Google, and Apple to agree on anything; this is the [end-to-end argument in systems design] in action.

tbrownaw• 16 years ago

HTTP Authentication is dead and is never coming back.

What should WebDAV shares use instead? I don't think form auth really works for that.

mjw4• 16 years ago

It's certainly not dead when it comes to RESTful web services APIs. It's often the best choice for authenticating these.

In a browser context, most of the UI criticisms have little to do with the protocol itself and could be easily addressed if browsers would add a little more HTML + javascript API support for doing HTTP auth logins and logouts. Admittedly that looks unlikely to happen in the near future, which is a shame IMO. IIRC they were considering it at one point for HTML5.

joshu2• 16 years ago

lcamtuf is amazing.

also: Lou Montulli did the blink tag. Hrmph!

tptacek17• 16 years ago

He really has gone from genuinely impressive to downright spooky in a pretty short period of time; he might be the smartest person doing browser security today.

That blog is just awesome, for what it's worth. He has yet to turn in a bad post.

joshu2• 16 years ago

I'm actually more enamored of the CAD and fabrication stuff: http://lcamtuf.coredump.cx/guerrilla_cnc1.shtml

HTTP cookies, or how not to design protocols

Related Stories