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

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> Sat, 13 February 2010 10:48 UTC

Return-Path: <yngve@opera.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 9D40428C106 for <http-state@core3.amsl.com>; Sat, 13 Feb 2010 02:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 QapETbcOra1W for <http-state@core3.amsl.com>; Sat, 13 Feb 2010 02:48:19 -0800 (PST)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 36F4828C100 for <http-state@ietf.org>; Sat, 13 Feb 2010 02:48:19 -0800 (PST)
Received: from acorna.oslo.opera.com (125.115.34.95.customer.cdi.no [95.34.115.125]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5) with ESMTP id o1DAj2C1029084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Feb 2010 10:45:38 GMT
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: Adam Barth <ietf@adambarth.com>, http-state <http-state@ietf.org>
References: <7789133a1002130001l6137f704va9e04a4edade1ee7@mail.gmail.com>
Date: Sat, 13 Feb 2010 11:48:56 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Organization: Opera Software AS
Message-ID: <op.u72azuuiqrq7tp@acorna.oslo.opera.com>
In-Reply-To: <7789133a1002130001l6137f704va9e04a4edade1ee7@mail.gmail.com>
User-Agent: Opera Mail/10.10 (Win32)
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: Sat, 13 Feb 2010 10:48:20 -0000

On Sat, 13 Feb 2010 09:01:08 +0100, Adam Barth <ietf@adambarth.com> wrote:

> The new draft that I've uploaded
> <http://www.ietf.org/id/draft-ietf-httpstate-cookie-03.txt> contains
> an updated and expanded Security Considerations section.  I've been
> circulating this section among security experts for feedback.  If you
> have some feedback on this section, I'd like to encourage you to let
> me know at this time.
>
> I've reproduced the Security Considerations section below for your  
> convenience.
>
> Thanks,
> Adam
>
>

> 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?


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.

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.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************