RE: Mozilla security review of Access Control

Jonas Sicking wrote:
> Close, Tyler J. wrote:
> > Sending the user's credentials without the user's consent
> > creates a host of security problems, such as the one around
> > headers the WG is currently struggling with and the one's
> > I've written about on this list recently, without enabling
> > any actually viable designs. For example, if the user's
> > credentials are not used, and the target resource has to
> > opt-in, it is OK to let the third-party web page specify
> > whatever headers it wants, so long as the HTTP request is
> > still well formed, since the third-party could have sent just
> > such a request from its own machine.
>
> All these problems exist even if we don't send cookies. The reason is
> intranet servers behind firewalls. These sites authenticate simply
> through the users ability to connect to the server.

Note that I included the clause ", and the target resouce has to opt-in," to catch the case of an intranet server that relies solely on the client's IP address to authenticate the client.

> I've argued this in the past (in a discussion on JSONRequest vs. AC
> iirc), that disabling cookies doesn't actually buy any reliably
> protection, but it does risk giving us (spec writers) a false sense of
> security.

Since not sending cookies does protect services that operate on the open Internet, it is a great exageration to say this measure "doesn't actually buy any reliably (sp) protection". A great number of valuable services are given clear protection by this measure.

To date, no one has presented a viable design that uses the user's cookies in a cross-domain request. There is a reason for that. It would be a neat trick indeed to claim you were enforcing the user's wishes, without ever getting any expression of those wishes from the user. Automatically sending cookies is a way of bypassing the step of getting the user's consent, when getting the user's consent is a necessary step in enforcing the user's wishes.

--Tyler