Re: [http-state] Security considerations overview

Mark Pauley <mpauley@apple.com> Thu, 04 March 2010 19:25 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 D53CB3A8DE5 for <http-state@core3.amsl.com>; Thu, 4 Mar 2010 11:25:33 -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.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 uNePHfAzGEKL for <http-state@core3.amsl.com>; Thu, 4 Mar 2010 11:25:32 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id E3A503A8C01 for <http-state@ietf.org>; Thu, 4 Mar 2010 11:25:32 -0800 (PST)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 33A138EEFC85; Thu, 4 Mar 2010 11:25:35 -0800 (PST)
X-AuditID: 11807137-b7bd4ae000000f0d-48-4b90092f1caf
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 BA.8A.03853.F29009B4; Thu, 4 Mar 2010 11:25:35 -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: <5c4444771003040533w32cb801ej9b16cee5775b667a@mail.gmail.com>
Date: Thu, 4 Mar 2010 11:25:34 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB63662B-3854-4652-B622-401F54E4B04B@apple.com>
References: <5c4444771003021103s422a65c3me96af57dfee58105@mail.gmail.com> <5691356f1003021438t1487d6d0g39439a2bdc3543ce@mail.gmail.com> <5c4444771003021452g44538236ta855abcfe6d578da@mail.gmail.com> <Pine.LNX.4.64.1003021508100.21569@egate.xpasc.com> <5c4444771003021539i2ed4ea44mf6b52970bc52385b@mail.gmail.com> <D88C1747-4C28-43DB-9BBD-5EB951CCD471@apple.com> <5691356f1003021640n22c2dc49j7939a2f4d19d1868@mail.gmail.com> <58FE8180-6A66-44B2-90AB-33F6FFE79779@apple.com> <B9FD2591-8A5A-46CA-A1E7-323868B23CF1@apple.com> <4B8F7591.6080509@securenet.de> <5c4444771003040533w32cb801ej9b16cee5775b667a@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] 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 19:25:34 -0000

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 <ah@securenet.de> 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