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

Adam Barth <ietf@adambarth.com> Mon, 08 February 2010 17:49 UTC

Return-Path: <adam@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 CECB23A720C for <http-state@core3.amsl.com>; Mon, 8 Feb 2010 09:49:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.543
X-Spam-Level:
X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5nucXo2T5V5r for <http-state@core3.amsl.com>; Mon, 8 Feb 2010 09:49:22 -0800 (PST)
Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id 7A8803A6A22 for <http-state@ietf.org>; Mon, 8 Feb 2010 09:49:22 -0800 (PST)
Received: by mail-yx0-f194.google.com with SMTP id 32so5265362yxe.5 for <http-state@ietf.org>; Mon, 08 Feb 2010 09:50:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.153.25 with SMTP id f25mr2525246wfo.168.1265651425093; Mon, 08 Feb 2010 09:50:25 -0800 (PST)
In-Reply-To: <4B704DC0.1070808@securenet.de>
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> <4B704DC0.1070808@securenet.de>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 8 Feb 2010 09:50:05 -0800
Message-ID: <7789133a1002080950v38c989a2w28fc05e6054c2513@mail.gmail.com>
To: Achim Hoffmann <ah@securenet.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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:49:27 -0000

On Mon, Feb 8, 2010 at 9:45 AM, Achim Hoffmann <ah@securenet.de> wrote:
> 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.

Thanks for participating.  Web application security is definitely an
important consideration for this group.

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

That is indeed what we're attempting to do.  The current draft
represents my understanding about how the cookie protocol works in
browsers.  Together with the deviation description document, that
should provide a detailed answer to your question.

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

Unfortunately, this discussion is not about voting for our favorite
cookie orderings.  We're merely documenting the cookie ordering that
already exists in implementations.

Adam