Re: Opting in to cookies - proposal

On 2008-06-16 12:00:29 -0700, Jonas Sicking wrote:

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

So, following your argument, why is the authorization mechanism
that's specified good enough for sites that use IP addresses (or,
more generally, firewalls) for authorization decisions, but not good
enough for cookies?

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

eh?  People who want to share public data will have to worry about
writing a policy, and any confusion that's caused by additional
complexity is going to extend to them.

As far as the public data use case is concerned, I'd also note that
that is precisely the use case in which a proxying approach is least
problematic, since there are no credentials that would be leaked.
The value of a browser-based cross-domain approach mostly manifests
itself for *private* data.

So, I'm not convinced that having a separate mechanism to opt in to
cookies (and other credentials) is really a useful choice here.

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

The original use case (from the voice browser world) was
specifically about private data that were accessed based on some
kind of ambient authorization.

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

See above; it removes the value of the PI for at least some of its
original use cases.  It also increases implementation and deployment
complexity.

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

Received on Thursday, 19 June 2008 10:45:15 UTC