Re: [http-state] Seeking feedback on Security Considerations

Adam Barth <ietf@adambarth.com> Sun, 14 February 2010 18:45 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 E4EAF3A7375 for <http-state@core3.amsl.com>; Sun, 14 Feb 2010 10:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.859
X-Spam-Level:
X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 AaKpI7YbDJZm for <http-state@core3.amsl.com>; Sun, 14 Feb 2010 10:45:43 -0800 (PST)
Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by core3.amsl.com (Postfix) with ESMTP id BF7C93A71FA for <http-state@ietf.org>; Sun, 14 Feb 2010 10:45:43 -0800 (PST)
Received: by iwn10 with SMTP id 10so1169538iwn.13 for <http-state@ietf.org>; Sun, 14 Feb 2010 10:47:07 -0800 (PST)
Received: by 10.231.153.1 with SMTP id i1mr4173996ibw.35.1266173227637; Sun, 14 Feb 2010 10:47:07 -0800 (PST)
Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by mx.google.com with ESMTPS id 21sm5485744iwn.14.2010.02.14.10.47.05 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Feb 2010 10:47:06 -0800 (PST)
Received: by iwn10 with SMTP id 10so1169519iwn.13 for <http-state@ietf.org>; Sun, 14 Feb 2010 10:47:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.167.204 with SMTP id r12mr4071911iby.31.1266173225361; Sun, 14 Feb 2010 10:47:05 -0800 (PST)
In-Reply-To: <op.u72azuuiqrq7tp@acorna.oslo.opera.com>
References: <7789133a1002130001l6137f704va9e04a4edade1ee7@mail.gmail.com> <op.u72azuuiqrq7tp@acorna.oslo.opera.com>
From: Adam Barth <ietf@adambarth.com>
Date: Sun, 14 Feb 2010 10:46:45 -0800
Message-ID: <5c4444771002141046k78a37fbh3aeae1ce95acbf5@mail.gmail.com>
To: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.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] Seeking feedback on Security Considerations
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: Sun, 14 Feb 2010 18:45:45 -0000

On Sat, Feb 13, 2010 at 2:48 AM, Yngve N. Pettersen (Developer Opera
Software ASA) <yngve@opera.com> wrote:
> On Sat, 13 Feb 2010 09:01:08 +0100, Adam Barth <ietf@adambarth.com> wrote:
>> 7.5.  Weak Integrity
>>
>>   Cookies do not provide integrity guarantees for sibling domains (and
>>   their subdomains).  For example, consider foo.example.com and
>>   bar.example.com.  The foo.example.com server can set a cookie with a
>>   Domain attribute of ".example.com", and the user agent will include
>>   that cookie in HTTP requests to bar.example.com.
>
> A bar.example.com can also overwrite a ".example.com" cookie set by
> foo.example.com. Maybe that should be mentioned?

Done.

> Another possible issues that maybe should be mentioned is that in shared
> hosting environments where multiple independent services are hosted in the
> same domain or on the same server it is possible for a malicious service to
> interfere with other services by setting cookies for domains and paths that
> will get them sent to other services.

Indeed.  I've added this paragraph:

[[
        <t>Even though the cookie protocol supports the Path attribute, the
        Path attribute does not provide any integrity protection because the
        user agent with accept an arbitrary Path attribute in a Set-Cookie
        header. For example, an HTTP response to a request for
        http://example.com/foo/bar can set a cookie with a Path attribute of
        "/qux". Consequently, servers SHOULD NOT both run mutually distrusting
        services on different paths of the same host and use cookies store
        security sensitive information.</t>
]]

> Should the fact that clients also support cookies through HTML meta tags and
> the Javascript document.cookie API be mentioned? The latter could be a
> concern when including external Javascripts directly into a HTML document.

Hum...  Maybe we should add a new section about interactions with non-HTTP APIs?

Adam