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

Adam Barth <ietf@adambarth.com> Sun, 14 February 2010 19:05 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 3DEAA3A73A5 for <http-state@core3.amsl.com>; Sun, 14 Feb 2010 11:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.862
X-Spam-Level:
X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.115, 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 mA3mDVhUjZ-L for <http-state@core3.amsl.com>; Sun, 14 Feb 2010 11:05:25 -0800 (PST)
Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by core3.amsl.com (Postfix) with ESMTP id 5C9AF3A68AC for <http-state@ietf.org>; Sun, 14 Feb 2010 11:05:25 -0800 (PST)
Received: by iwn42 with SMTP id 42so4378738iwn.29 for <http-state@ietf.org>; Sun, 14 Feb 2010 11:06:50 -0800 (PST)
Received: by 10.231.167.65 with SMTP id p1mr2875388iby.20.1266174410067; Sun, 14 Feb 2010 11:06:50 -0800 (PST)
Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx.google.com with ESMTPS id 20sm5505795iwn.1.2010.02.14.11.06.48 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Feb 2010 11:06:48 -0800 (PST)
Received: by iwn42 with SMTP id 42so4378728iwn.29 for <http-state@ietf.org>; Sun, 14 Feb 2010 11:06:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.150.74 with SMTP id x10mr6412167ibv.97.1266174408133; Sun, 14 Feb 2010 11:06:48 -0800 (PST)
In-Reply-To: <4B76B98E.9040606@gmail.com>
References: <7789133a1002130001l6137f704va9e04a4edade1ee7@mail.gmail.com> <4B76B98E.9040606@gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Sun, 14 Feb 2010 11:06:28 -0800
Message-ID: <5c4444771002141106w602a4c59y7052f10bd89c911f@mail.gmail.com>
To: Dan Winship <dan.winship@gmail.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 19:05:29 -0000

On Sat, Feb 13, 2010 at 6:39 AM, Dan Winship <dan.winship@gmail.com> wrote:
> On 02/13/2010 03:01 AM, Adam Barth wrote:
>> 7.3.  Clear Text
>>    In addition to encrypting and signing the contents of every cookie,
>>    servers that require a higher level of security SHOULD use the cookie
>>    protocol only over a secure channel.
>
> Should probably mention the problem of having to explicitly set the
> "Secure" flag too.

Haha, indeed.

>> 7.4.  Weak Confidentiality
>
>>    Cookies do not provide isolation by port.
>>    Cookies do not provide isolation by scheme.
>
> Also path.

This is slightly more subtle than the other cases because the
confidentiality problems have to do with other user agent
functionality rather than the cookie protocol itself:

[[
        <t>Cookies do not always provide isolation by path. Although the
        network-level protocol does not send cookie stored for one path to
        another, some user agents expose cookies via non-HTTP APIs, such as
        HTML's document.cookie. Because some of these user agents (e.g., web
        browsers) do not isolate resources received from different paths, a
        resource retrieved from one path might be able to access cookies
        stored for another path.</t>
]]

Note that I've also added a paragraph under "integrity" about the
integrity problems w.r.t. path (and these problems are inherent in the
protocol itself):

[[
        <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>
]]

>>    Although most commonly
>>    used with the http and https schemes, the cookies for a given host
>>    are also available to other schemes, such as ftp and gopher.
>
> Do we know that this is consistent across browsers?

I think so, but I haven't tested it rigorously.

> Should have some tests for that.

Yeah, but we don't have a good harness for non-HTTP tests yet.

> If it's not, we can just change "are also available" to
> "may also be available" though.

Done.

>>    This
>>    lack of isolation is most easily seen when a user agent retrieves a
>>    URI with a gopher scheme via HTTP, but the lack of isolation by
>>    scheme is also apparent via non-HTTP APIs that permit access to
>>    cookies, such as HTML's document.cookie API.
>
> I think retrieving an HTML+javascript page via ftp is about a zillion
> times more "easily seen" than anything involving gopher. :)

Haha, yeah.  I just meant that the problem exists in the protocol
itself and not just in HTML user agents.  I've reversed the order here
to give the more normal example before the pedantic example.

Adam