Close, Tyler J. wrote:
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.
Right, and this applies if we're sending cookies too.
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.
I would still say it doesn't buy us any reliably protection. There are
no changes we can make to the spec if we say that cookies should not be
sent. For example it doesn't make it any safer to send custom headers,
and it doesn't make it any safer to use unsafe methods when connecting
to the server.
The only thing it does buy us is that it protects a lot (but not all)
servers that are misconfigured by server operators that have
misunderstood the spec.
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.
I can see several designs where sending cookies is beneficiary and safe.
First of all cookies doesn't have to be used for authentication, it can
be used simply as a way to track a session. So if the requesting site
makes several connections to the target server, the target server can
keep track of which ones come from the same session.
Another scenario is when there really is full trust between two servers.
For example www.google.com and www.youtube.com are both run by the same
company and so transferring user data between the two is no more of a
privacy issue than giving you data too google.com in the first place.
For mashups, the scenario that I think would be the most useful is if
sites that hold personal information provide a way for users to
whitelist which mashup sites they trust with their personal information.
So they could host a page where i simply list the domains that I want to
give access to my personal information. When a mashup site then makes a
request to google they can reply with a 'allow' rule that lists those
domains.
I'm sure Hixie has lots more safe scenarios where google had planned to
use Access-Control
/ Jonas
