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.
The potential benefit is... what, exactly?
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.
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.
The only other scheme I know of to defend against XSRF is to generate secret values for every request, which is not always practical.
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?).
I don't like keeping per-request state on the server, else I would use random CSRF tokens.
* 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.
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.
Is there not any scope for improvement on this front using alternative HTTP auth schemes though? (As far as I'm aware the standard has room for schemes other than Basic and Digest, although I suppose limited to the challenge-response format)
At any rate, it'd be nice if there was an effort to work with the HTTP standard (or if not possible, propose extensions to it) and aim for clean protocol design where at all possible when driving to improve API security.
SSL + HTTP Auth has been pretty good for us, and it's a good fit for the RESTful design goals of the protocol, so I'd be sad to see it thrown out, rather than improved where necessary.
If there's a single advantage to conveying a username/password in a dedicated HTTP header as opposed to any other way of using HTTP to convey the same information, it hasn't been well articulated to me. Down with HTTP Authentication!
Host - necessary for multiplexing over the predominant transport protocol
Date - necessary for caching
Referer - mostly useless and optional anyway
User-Agent - information about the client and essentially useless
Server - useless
And then there are the bastard children:
Cookie/Set-Cookie - used to turn HTTP into a stateful protocol
Authorization/WWW-Authenticate - used to transmit information about the relationship between the client and server.
The statelessness of HTTP is one of its major strong points, making it easy to load-balance and scale, more easily compatible with a wide range of middleware, etc. The redundancy involved in repeating certain headers is a design trade-off made for a reason.
There's a bunch of trade-offs here in the protocol design though, evidently. Coming at it from a security perspective seemingly leads to a different view of those tradeoffs than (say) Fielding has.
If you have an application with a really pressing need for stateful session-level protocol features though -- perhaps HTTP isn't the best choice anyway?
SAML is a better auth mechanism for REST services.
What should WebDAV shares use instead? I don't think form auth really works for that.
* Browser specific UI, which leads to:
* No place to put password recovery links
* No place to put explanatory text
* No mechanism for logout
If either (a) or (b) do not hold, Basic Auth is at least as hard as cookie auth.
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.
The only large public website that I know of which still uses HTTP Authentication though is http://www.123-reg.co.uk/
curl --anyauth --user login:password https://example.com/
But my point is just: HTTP Auth is not the best-practices answer to non-browser web services auth. Both API-key and signed URLs are both competitive (and probably better) options.
(1) For most large apps, you're not really SSL in the provider's own network, so there's always the cross-app risk if something horrible happens.
(2) It's forcing app-to-app, business-to-business authentication into a username/password mold that doesn't many any real sense; a 128 bit random key (or an SSL client cert) makes more sense anyways.
Against those two problems --- which are marginal, I concede --- HTTP Basic offers... exactly what advantage? I don't see it.
also: Lou Montulli did the blink tag. Hrmph!
That blog is just awesome, for what it's worth. He has yet to turn in a bad post.
On the face of it that seems the case.