Re: Opting in to cookies - proposal

Thomas Roessler wrote:
> 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.

We unfortunately do have to authorize requests even without sending
cookies. This is to protect content behind firewalls. This is
unfortunate but I don't see a way around this.

> - 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!)

Yes, but that should be a smaller set of people since the people that 
only want to share public data won't have to worry. So the result should 
be fewer exploitable sites.

Sharing private data is always going to be tricky. Not least since the 
site has to get the user in the loop and ask him/her before sharing the 
data with unknown third parties.

> 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.

I'm fine with removing the nested scheme and using an out-of-band 
boolean flag instead.

>> 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?

Yes. The PI pretty much only makes sense for static files anyway, which 
usually contain public data.

>> 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.

It significantly reduces the security risk of having the PI in the spec. 
That sounds like a good thing to me.

/ Jonas

Received on Monday, 16 June 2008 19:01:51 UTC