Subject: [http-state] Setting cookies for sibling domains (was Re: Security considerations overview)

From: Adam Barth <[email-masked]>
Date: Wed, 3 Mar 2010 15:40:47 -0800

On Wed, Mar 3, 2010 at 3:38 PM, Mark Pauley <[email-masked]> wrote:
> 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.

Oh, I thought I tested that case.  Give me a few minutes to write a
test case for this behavior.

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

I find that surprising, but that's why we have tests.  :)

Adam

> On Mar 3, 2010, at 3:32 PM, Mark Pauley wrote:
>
>> Excuse my ignorance, I've just recently joined this list.
>>
>> Is this the correct forum to enquire about what we refer to as the 'Cross Site Acceptance Policy'?  We (Safari / CFNetwork) by default refuse to set cookies from hosts from a domain tree outside of the current Top Level Domain tree.  That is from a host with name x1.x2.x3...x_k  we'll set a cookie with domain .y1.y2.y3...y_m if and only if y_m == x_k, y_m-1 == x_k-1, etc to y_m-n == x_k-n and y1....y_m-n is not a top level domain.
>>
>> That is, if the domain is at least a cousin; the target domain shares a common ancestor with the origin domain which is not a Top Level Domain.
>>
>> We've worked out that this is probably the most restrictive definition that will work given a good enough description of what a Top Level Domain is (which we have thanks to the Mozilla Top Level Domain list project).
>>
>>
>> _______________________________________________
>> http-state mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/http-state
>
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>

---

From: Adam Barth <[email-masked]>
Date: Wed, 3 Mar 2010 16:03:51 -0800

> I find that surprising, but that's why we have tests.  :)

I'm not able to reproduce this behavior with Safari 4.0.4.  Here's my test case:

http://subdomain.home.example.org:8888/cookie-parser?domain0042 responds with

Set-Cookie: foo=bar; domain=.sibling.home.example.org
Location: http://sibling.home.example.org:8888/cookie-parser-result?domain0042

but no cookie is sent when requesting
http://sibling.home.example.org:8888/cookie-parser-result?domain0042.

Is there something I'm doing wrong?

If you want to try this at on your own machine, you can "git clone
git://github.com/abarth/http-state.git" and then follow the
instructions at
<http://github.com/abarth/http-state/blob/master/tests/README>.  (Note
that this test case doesn't quite fit into our testing harness because
we need to start on subdomain.home.example.org instead of the usual
home.example.org.)

Thanks,
Adam

---

From: Mark Pauley <[email-masked]>
Date: Wed, 3 Mar 2010 16:21:44 -0800

Ah, you're right!  I apologize.

What I meant to say is that if one of your sub-resources is sibling.home.example.org, and the main document url is subdomain.home.example.org, the response from the sibling.home.example.org request will be able to set a cookie on .home.example.org

My apologies for the confusion.  We won't allow you to break the rule that you can only set a cookie for a parent domain, but we also will only allow responses from hosts that are cousins to set cookies, so that for example stalkersite.doubleclick.net can't easily tell that you've been to subdomain.home.example.org.

---

From: Adam Barth <[email-masked]>
Date: Wed, 3 Mar 2010 17:09:48 -0800

> Ah, you're right!  I apologize.

No need to apologize.  The cookie protocol is surprisingly complicated.

> What I meant to say is that if one of your sub-resources is sibling.home.example.org, and the main document url is subdomain.home.example.org, the response from the sibling.home.example.org request…

Yes, that should be covered in the current draft.

> My apologies for the confusion.  We won't allow you to break the rule that you can only set a cookie for a parent domain, but we also will only allow responses from hosts that are cousins to set co…

You seem to be referring to Safari's default third-party cookie
blocking.  The spec allows, but does not encourage, third-party cookie
blocking.  Note that Safari blocks setting of cookies in a third-party
context whereas some other user agents block getting third-party
cookies in some configurations.

Adam