Ian Hickson wrote:
On Tue, 12 Feb 2008, John Panzer wrote:
(Though they might need to use different headers, of course -- we
obviously can't allow scripts doing cross-origin requests to
arbitrarily change HTTP authenticiation headers.)
Sorry, it's not obvious to me. We're talking about a situation where
the server has explicitly opted in to CSRs. I can understand not
sending authorization data from the browser itself by default, maybe,
but to block scripts from setting a header seems unnecessary and will
just lead to X-Authorization:.
There's no way we can allow a distributed authorisation credentials attack
on systems using username/password authentication or cookie authentication
mechanisms. The browser vendors just wouldn't let implement anything that
allowed that.
What mechanism do you propose clients and servers implement use to
authenticate users for CSR requests? Because servers have to implement
_something_. Realistic mechanisms have to be resistant to distributed
brute force attacks even without AC4CSR (thank you, Storm Worm).
On a side note, I hope that servers opting in to CSR would never
consider using username/password auth on each request. Since it is
possible to implement username/password auth in ways opaque to browsers
("&u=foo&pass=bar"), perhaps this is worth a note in the security section.
John
