Re: [http-state] Security considerations overview

[Mark Pauley <[e-mail]>]

Sorry, this was confusion on my part, we cleared this up.  We (CFNetwork / Safari) don't allow sibling domains to be set via cookies.  We do restrict the hosts that can set cookies based on the 'Main Document' URL.  A response from a request for a sub-resource is considered not a 3rd-party response if it came from a host that shares a non- top level domain postfix with the Main Document URL's host.  

So we won't let you set .bar.example.com from foo.example.com, but we will let you set .example.com from foo.example.com, which of course can cause a race where bar.example.com thinks it's got a valid session.

My confusion is that if you load foo.example.com, which has an embedded image loaded from www.advertisement.com, we will fail to set any cookies in the response for the request for that image.  This is of course only for the default 'Do not allow 3rd party cookies' setting.



On Mar 4, 2010, at 5:33 AM, Adam Barth wrote:

> On Thu, Mar 4, 2010 at 12:55 AM, Achim Hoffmann <[e-mail]> wrote:
>> Mark Pauley wrote on 04.03.2010 00:38:
>>> It would appear that this is covered by 4.1.2.2
>>> 
>>> We (and many other browsers) do allow setting a cookie with domain .bar.example.com from .foo.example.com
>>> 
>>> Indeed, some web applications rely on this behavior.  The compromise is that we'll allow .foo.example.com to set a cookie for .bar.example.com if and only if .example.com is not a Top Level (or registry controlled) Domain.
>> 
>> outch.
>> That's exactly why 7. Security Consideration writes:
>> 
>>   Cookie protocol is NOT RECOMMENDED for (new) applications.
>> 
>> (my personal opinion for *secure* applications would be: FORBIDDEN ;-)
>> Achim
> 
> FWIW, that section doesn't say that anymore.
> 
> Adam