Re: [http-state] Security considerations overview

Adam Barth <> Tue, 02 March 2010 23:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CE163A8ABE for <>; Tue, 2 Mar 2010 15:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rzSJb-IJZthU for <>; Tue, 2 Mar 2010 15:39:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 820383A7A68 for <>; Tue, 2 Mar 2010 15:39:37 -0800 (PST)
Received: by yxe26 with SMTP id 26so460123yxe.29 for <>; Tue, 02 Mar 2010 15:39:34 -0800 (PST)
Received: by with SMTP id l19mr305379ybg.90.1267573174630; Tue, 02 Mar 2010 15:39:34 -0800 (PST)
Received: from ( []) by with ESMTPS id 22sm4536874iwn.8.2010. (version=SSLv3 cipher=RC4-MD5); Tue, 02 Mar 2010 15:39:33 -0800 (PST)
Received: by iwn9 with SMTP id 9so884826iwn.17 for <>; Tue, 02 Mar 2010 15:39:33 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id o13mr342450ibx.13.1267573173089; Tue, 02 Mar 2010 15:39:33 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Adam Barth <>
Date: Tue, 2 Mar 2010 15:39:13 -0800
Message-ID: <>
To: http-state <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [http-state] Security considerations overview
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Mar 2010 23:39:38 -0000

On Tue, Mar 2, 2010 at 3:27 PM, David Morris <> wrote:
> No. Network attacks that impact HTTPS in general should not be used
> to claim that cookies, by default, are not secure. Network infrastructure
> manipulation which would reveal totally HTTPS website cookie content would
> also expose everything else about the HTTP based application to intercept,
> manipulation, etc.

We're not talking about vulnerabilities in HTTPS or TLS.  We're
talking about the default behavior of the cookie protocol itself,
which does not provide confidentiality from network attackers.

> I still don't see the actual vulnerability, and haven't yet reviewed
> the backing details, but I think that makes me the typical reader of
> the summary. If what I read in the summary doesn't make sense, I'll
> probably ignore the details.

The issue is quite simple:

1) In an HTTPS response, the server responds with
"Set-Cookie: foo=bar".  By default (i.e., without the optional Secure
attribute), this cookie does not have the secure-only-flag set.
2) The user agent makes a single HTTP request.
3) The network attacker spoofs an HTTP response that contains an HTTP
redirect to
4) The user agent follows the redirect and sends the cookie foo in the
clear, where it can be observed by the attacker.

> Furthermore, I suspect these vulnerabilities depend on the specific
> User-Agent implemenation.

No.  The vulnerability is in the design of the protocol.

> The executive summary needs to provide an accurate description of
> the issue. I'd try to suggest an alternate set of words, but I don't yet
> understand the basis of the claim.

The issue is described in detail later in the section.

> The generic summary statement proposed below applies equally to anything
> associated with HTTP. By default the content isn't secure. If that is what
> you mean, than say something like:
>   Cookies as a subset of the HTTP protocol share all of the security
>   vulnerabilities of HTTP and in some cases may excerbate the
>   issues because of the possible leakage of cookie content to
>   unintended servers...

That summary is insufficiently harsh.  The cookie protocol has a
number of design errors that impair its security far more than the
rest of the HTTP protocol.