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
- [http-state] Seeking feedback on Security Conside… Adam Barth
- Re: [http-state] Seeking feedback on Security Con… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [http-state] Seeking feedback on Security Con… Dan Winship
- Re: [http-state] Seeking feedback on Security Con… Adam Barth
- Re: [http-state] Seeking feedback on Security Con… Adam Barth
- Re: [http-state] Seeking feedback on Security Con… Achim Hoffmann
- Re: [http-state] Seeking feedback on Security Con… Achim Hoffmann