Re: Opting in to cookies - proposal

On 2008-06-13 16:56:16 -0700, Jonas Sicking wrote:

> First off, as before, when I talk about "cookies" in this mail I really
> mean cookies + digest auth headers + any other headers that carry the
> users credentials to a site. However i'll just use the term "cookies"
> for readability, and since that is on the web currently the most
> common carrier of credentials.

As I said in [1], I think this is pointless.

- Requests without cookies can be sent by the attacker anyway (but
  from a different IP address); there is little to no point in
  having a separate mechanism to authorize these requests coming
  from the client.

- Any arguments that apply to the authorization mechanism as
  specified now (e.g., that people don't understand what they are
  doing, and will therefore write bad policies) will likewise apply
  to an authorization mechanism that is specific to requests with
  ambient authorization. (Wait, that's where we started out with
  this!)

Just don't do this.

1. http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0083.html

> When the resource is loaded using an URI which starts with the string
> "user-private:" set the "with credentials" flag to true. Otherwise set
> it to false.

I agree with Maciej that this is highly distasteful. Don't do this.

> The result of this is that adding the header
> "Access-Control-Allow-Credentials: all" allows the server to opt
> in to receiving cookies. This header is only applied to
> Access-Control headers, not <?Access-Control?> PIs.

So we're now having two levels of authorizations -- some things can
be done from the PI, and some can only be done from headers?  Don't
do this.

> A nice side effect is that is that if there is no way to use
> cookies together with the <?Access-Control?> PI. This means that
> if an attacker somehow manages to modify the content of a reply
> in such a way that a Access-Control PI is inserted, most of the
> time no dangerous requests can be made, and no private data can
> be leaked. The exception is when the server is protected by a
> firewall, however that is much less common, especially for such
> servers to participate in mashups.

Additional inconsistency strikes me as even more of a mis-feature.
Don't do this.

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Saturday, 14 June 2008 09:40:08 UTC