
HTTP cookies, or how not to design protocols - tptacek
http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html
======
Udo
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

~~~
mike-cardwell
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.

~~~
tptacek
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.

~~~
jacquesm
No cost, potential benefit. I've had to make harder decisions.

~~~
tptacek
The cost is "false sense of security", and believe me, from field work, that
is a real cost. A majority of programmer applicants can't solve FizzBuzz, so
you're deluded if you think that a good chunk of webdevs don't think "HttpOnly
fixes XSS".

The potential benefit is... what, exactly?

~~~
Udo
It lessens your potential attack surface and comes at no cost. And as
security-ignorant devs are concerned (which we all are from time to time) it
doesn't magically fix vulnerabilities, but it can alleviate the magnitude of
exploits. It's a good idea.

~~~
tptacek
Try to articulate how it lessens the attack surface. It means you can't bank
up session tokens; instead, you're only able to do everything that a session
token would do for you anyhow. Remember in your explanation that session
tokens already expire anyways.

~~~
Udo
By sending the HttpOnly flag as a server application, I indicate to the
browser that it should prevent client-side scripts from obtaining the actual
value of the cookie. Hence, it is more difficult for a malicious little piece
of smuggled-in XSS code to steal my session id and ship it off to some
Nigerian server. Is it circumventable? Yes. Are different browser
implementations subverting this scheme? Yes. But is the intention behind it
worthwhile? ...I think so.

Of course, that kind of protection is superficial, but please try to remember
in your rebuttal there are actual attacks still happening that could have been
prevented by setting this simple flag. An insistence on always making secure
code that won't have this problem anyway is honorable but not realistic. By
the way, it happens on high profile sites, too. It shouldn't, and it makes us
web devs uncomfortable even observing it from a distance, but it still
happens.

Even disregarding this argument, for me HttpOnly is the way cookies should
have been conceived by default. I believe accessing cookie values by
JavaScript is pathological. The behavior HttpOnly attempts to trigger on the
client seems like good practice to me, and given (again) the point that it
comes at no cost to the reasonable developer, turning it on is really a no-
brainer. In fact, browsers should turn it on whether the flag is set or not.

 _It means you can't bank up session tokens; instead, you're only able to do
everything that a session token would do for you anyhow._

Oh, you can still use other exploits to bank up tokens, but yes this
particular avenue is blocked. You're absolutely right, having the current
session to work with is pretty destructive. But I think shipping off session
IDs to a hostile server is worse than issuing false requests on behalf of the
user in an already open browser window. That's because siphoning session IDs
is silent and can lead to problems many days later when you're _not_ online.

 _Try to articulate [...] Remember in your explanation that session tokens
already expire anyways._

Alright, I'll try not to drool and babble more than necessary: for the sake of
convenience we are used to very long-lasting session tokens. So when you say
they expire, yes, it limits the amount of damage somewhat, but not in any
meaningful way considering the typical cookie-based account identifier lasts
well beyond a week. Certainly for the purpose of completing my answer I can
now say "I remembered" session expiration but it didn't really go anywhere.

------
clark
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.

~~~
psadauskas
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.

~~~
tptacek
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.

~~~
mike-cardwell
I use HTTP authentication when I want to password protect a bunch of static
files, or a third party web app. Using the PAM auth module with Apache is
particularly nice. Just drop a few lines in a .htaccess file and it uses your
users system credentials, eg /etc/passwd and /etc/shadow.

HTTP Authentication comes in several flavours. I've not done it myself, but I
think you can do interesting things to with Kerberos. Good for Intranet
systems.

HTTP Authentication does have its places.

~~~
tptacek
In other words, HTTP Authentication is useful in the same sense as FTP is
useful: it's outmoded but sometimes convenient.

~~~
mike-cardwell
HTTP Authentication is sessionless. In any scenario where you want to protect
something without establishing and maintaining a session, it's useful.

The only large public website that I know of which still uses HTTP
Authentication though is <http://www.123-reg.co.uk/>

~~~
tptacek
What's the browser app scenario in which having a session is a liability, but
having a stored HTTP Auth credential isn't?

~~~
kls
Actually the elimination of server side session reduces distributed
application topology significantly. It is far easier to scale a stateless app
than it is a statefull app.

------
joshu
lcamtuf is amazing.

also: Lou Montulli did the blink tag. Hrmph!

~~~
tptacek
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.

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

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

On the face of it that seems the case.

