Re: [http-state] Ticket 5: Cookie ordering

Achim Hoffmann <ah@securenet.de> Mon, 08 February 2010 17:44 UTC

Return-Path: <ah@securenet.de>
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 AEFDB3A7461 for <http-state@core3.amsl.com>; Mon, 8 Feb 2010 09:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6]
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 WSImsbQVf9xs for <http-state@core3.amsl.com>; Mon, 8 Feb 2010 09:44:33 -0800 (PST)
Received: from munich.securenet.de (munich.securenet.de [82.135.17.200]) by core3.amsl.com (Postfix) with ESMTP id 4E1873A720C for <http-state@ietf.org>; Mon, 8 Feb 2010 09:44:33 -0800 (PST)
Received: from oxee.securenet.de (unknown [10.30.18.40]) by munich.securenet.de (Postfix) with ESMTP id B707B27191 for <http-state@ietf.org>; Mon, 8 Feb 2010 18:45:34 +0100 (CET)
Received: by oxee.securenet.de (Postfix, from userid 65534) id 8336E1402036; Mon, 8 Feb 2010 18:45:34 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by oxee.securenet.de (Postfix) with ESMTP id 734961402436; Mon, 8 Feb 2010 18:45:32 +0100 (CET)
Received: from oxee.securenet.de ([127.0.0.1]) by localhost (oxee.securenet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05181-01; Mon, 8 Feb 2010 18:45:32 +0100 (CET)
Received: from [10.30.18.9] (krakatau.securenet.de [10.30.18.9]) by oxee.securenet.de (Postfix) with ESMTP id 4DD651402427; Mon, 8 Feb 2010 18:45:32 +0100 (CET)
Message-ID: <4B704DC0.1070808@securenet.de>
Date: Mon, 08 Feb 2010 18:45:36 +0100
From: Achim Hoffmann <ah@securenet.de>
Organization: SecureNet
User-Agent: who">cares?
MIME-Version: 1.0
To: yngve@opera.com
References: <7789133a1001191410l48530adar28098a03e6de0fb1@mail.gmail.com> <op.u7mkruzjvqd7e2@killashandra.oslo.osa> <alpine.DEB.2.00.1002050932580.3094@tvnag.unkk.fr> <op.u7nnk8uyvqd7e2@killashandra.oslo.osa> <op.u7tgx5y4vqd7e2@killashandra.oslo.osa>
In-Reply-To: <op.u7tgx5y4vqd7e2@killashandra.oslo.osa>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Open-Xchange Express amavisd-new at oxee.securenet.de
Cc: Achim <achim@owasp.org>, Daniel Stenberg <daniel@haxx.se>, http-state <http-state@ietf.org>
Subject: Re: [http-state] Ticket 5: Cookie ordering
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: Mon, 08 Feb 2010 17:44:34 -0000

Hi all,

even I'm listening to the list since the beginning, I'd kept quit 'cause
my main interest is about cookies and web application security.

Anyway, it's time to speak as the cookie oder/sequence seems to be a
mystery since ages. See my question years back and still no answer
(except those in this list now:)
	http://www.webappsec.org/lists/websecurity/archive/2005-11/msg00097.html

'til now we got a clear statement from Opera (thanks Yngve), but there're
more  browser vendors on the list. What is so difficult to make a clear
and undoubtfull statement how it works in each browser?

The cookie sequence is really important as I'm aware of some serious
attacks (miss)using this sequence.
It needs to be fixed, so we can tell application developers how to deal
with a list of cookies with the same name (unless someone implements
Cookie2 in major browsers again:)

My vote for a sequence (with security in mind) would be:
  1. most qualified first
    a) protocol, always all HTTPS before HTTP (exception see e))
    b) FQDN (domains MUST be IDN, other characters MUST be transformed to IDN)
    c) port
    d) path
    e) secure Flag
    f) timestamp
    g) wildcard (domain) cookies at very last
  2. above order MUST not change if the browser's cookie store is
     overflowed

Do I miss something?
Cheers,
Achim



Yngve Nysaeter Pettersen wrote on 08.02.2010 17:19:
> On Fri, 05 Feb 2010 13:56:58 +0100, Yngve Nysaeter Pettersen
> <yngve@opera.com> wrote:
>> IOW, if ordering is determined by anything but the domain and path the
>> sequence of cookie is going to vary depending on which servers the
>> clients visits and the sequence it visits them, and this might cause
>> significant problems for a server that considers ordering significant.
> 
> Some testing by a couple of my colleagues setting two cookies with the
> same name (and path) "host-only" and "domain-wide" have found the
> following in browsers other than Opera:
> 
> -----
> Visit order: Host-only, domain-wide
> Cookie order:  "host-only", "domain-wide"
> -----
> 
> -----
> Visit order: domain-wide, Host-only
> Cookie order (IE):  "host-only", "domain-wide"
> Cookie order (Others): "domain-wide", "host-only"
> -----
> 
> To me it looks like IE is sorting by domain, at the same path level,
> with FF and Safari (the two tested) sort on creation data.
> 
> The consequence is that there is apparently three deployed ways to send
> cookies:
> 
>    - Cookies at the same path level are grouped and sorted by creation
> date, earliest first (FF&co)
>    - Cookies at the same path level are grouped and sorted by domain,
> most specific first (IE)
>    - Cookies are grouped by domain (most specific first), then sorted by
> path (most specific first) within each domain (Opera)
> 
> IMO the creation date method is less predictable than the other two, and
> will cause problems for sites depending on a specific sequence of cookies.
> 
> My suggestion would be that the spec should recommend ordering an
> ordering based on on both domain and path (order of preference to be
> decided), as that will be more predictable for sites using multiple
> cookies with the same name at various domain and path levels.
>