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

Mark Pauley <mpauley@apple.com> Thu, 04 March 2010 00:21 UTC

Return-Path: <mpauley@apple.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 7BF1B3A89DD for <http-state@core3.amsl.com>; Wed, 3 Mar 2010 16:21:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100, 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 y5nPdQgo61DW for <http-state@core3.amsl.com>; Wed, 3 Mar 2010 16:21:46 -0800 (PST)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 9835D3A89D9 for <http-state@ietf.org>; Wed, 3 Mar 2010 16:21:42 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 588D5879DC69; Wed, 3 Mar 2010 16:21:44 -0800 (PST)
X-AuditID: 11807137-b7bd4ae000000f0d-f3-4b8efd18664d
Received: from il0301a-dhcp53.apple.com (il0301a-dhcp53.apple.com [17.203.14.181]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id D0.35.03853.81DFE8B4; Wed, 3 Mar 2010 16:21:44 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=us-ascii
From: Mark Pauley <mpauley@apple.com>
In-Reply-To: <5c4444771003031603q77d84c02x79e6952535e8bd0a@mail.gmail.com>
Date: Wed, 3 Mar 2010 16:21:44 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <29453A1B-3FBF-4F2E-9870-89DD18D3D4BC@apple.com>
References: <5c4444771003031540j3d1092dbx2dfa2dc4d455dfe8@mail.gmail.com> <5c4444771003031603q77d84c02x79e6952535e8bd0a@mail.gmail.com>
To: Adam Barth <ietf@adambarth.com>
X-Mailer: Apple Mail (2.1078)
X-Brightmail-Tracker: AAAAAQAAAZE=
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 00:21:48 -0000

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.



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