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

Adam Barth <ietf@adambarth.com> Thu, 04 March 2010 01:10 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5963A89EE for <http-state@core3.amsl.com>; Wed, 3 Mar 2010 17:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, WEIRD_PORT=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsnpEJaQj2VP for <http-state@core3.amsl.com>; Wed, 3 Mar 2010 17:10:13 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 5D7063A89EB for <http-state@ietf.org>; Wed, 3 Mar 2010 17:10:13 -0800 (PST)
Received: by gwb10 with SMTP id 10so1107369gwb.31 for <http-state@ietf.org>; Wed, 03 Mar 2010 17:10:12 -0800 (PST)
Received: by 10.101.183.4 with SMTP id k4mr3856873anp.39.1267665009471; Wed, 03 Mar 2010 17:10:09 -0800 (PST)
Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.223.182]) by mx.google.com with ESMTPS id 21sm39803iwn.7.2010.03.03.17.10.08 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Mar 2010 17:10:08 -0800 (PST)
Received: by iwn12 with SMTP id 12so1651277iwn.21 for <http-state@ietf.org>; Wed, 03 Mar 2010 17:10:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.167.135 with SMTP id q7mr795562iby.84.1267665008126; Wed, 03 Mar 2010 17:10:08 -0800 (PST)
In-Reply-To: <29453A1B-3FBF-4F2E-9870-89DD18D3D4BC@apple.com>
References: <5c4444771003031540j3d1092dbx2dfa2dc4d455dfe8@mail.gmail.com> <5c4444771003031603q77d84c02x79e6952535e8bd0a@mail.gmail.com> <29453A1B-3FBF-4F2E-9870-89DD18D3D4BC@apple.com>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 03 Mar 2010 17:09:48 -0800
Message-ID: <5c4444771003031709n7698b658sf742368da7a24573@mail.gmail.com>
To: Mark Pauley <mpauley@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Setting cookies for sibling domains (was Re: Security considerations overview)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Mar 2010 01:10:14 -0000

On Wed, Mar 3, 2010 at 4:21 PM, Mark Pauley <mpauley@apple.com> wrote:
> 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 will be able to set a cookie on .home.example.org

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 cookies, so that for example stalkersite.doubleclick.net can't easily tell that you've been to subdomain.home.example.org.

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


> On Mar 3, 2010, at 4:03 PM, Adam Barth wrote:
>> On Wed, Mar 3, 2010 at 3:40 PM, Adam Barth <ietf@adambarth.com> wrote:
>>> On Wed, Mar 3, 2010 at 3:38 PM, Mark Pauley <mpauley@apple.com> 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.  :)
>>
>> 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
>
>