Re: [http-state] Security considerations overview

Adam Barth <> Wed, 03 March 2010 00:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 306FC28C133 for <>; Tue, 2 Mar 2010 16:15:48 -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 zTafP64wD8SO for <>; Tue, 2 Mar 2010 16:15:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 015F13A8CC0 for <>; Tue, 2 Mar 2010 16:15:46 -0800 (PST)
Received: by gwb10 with SMTP id 10so515990gwb.31 for <>; Tue, 02 Mar 2010 16:15:44 -0800 (PST)
Received: by with SMTP id k35mr285167ann.50.1267575344123; Tue, 02 Mar 2010 16:15:44 -0800 (PST)
Received: from ( []) by with ESMTPS id 21sm4585525iwn.7.2010. (version=SSLv3 cipher=RC4-MD5); Tue, 02 Mar 2010 16:15:43 -0800 (PST)
Received: by iwn9 with SMTP id 9so917293iwn.17 for <>; Tue, 02 Mar 2010 16:15:42 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id y13mr70127ibw.27.1267575342170; Tue, 02 Mar 2010 16:15:42 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Adam Barth <>
Date: Tue, 2 Mar 2010 16:15:22 -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: Wed, 03 Mar 2010 00:15:48 -0000

On Tue, Mar 2, 2010 at 4:04 PM, David Morris <> wrote:
> On Tue, 2 Mar 2010, Adam Barth wrote:
>> 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.
> That case was excluded by my earlier restriction to all HTTP.

Even if a web server operates exclusively over HTTPS, general purpose
user agents are willing to issue HTTP requests.

>> 3) The network attacker spoofs an HTTP response that contains an HTTP
>> redirect to
> Only applies if there is an HTTP server on the same host. And it requires
> a vulnerable infrastructure at either end of the connection.

We're discussing a network attacker.  A network attacker can spoof an
HTTP response from a host even if that host is not operating an HTTP
server.  Likewise, a network attacker can intercept an HTTP request to
a host even if that host is not operating an HTTP server.

> This also suggests some issues with HTTP redirect which have not been
> discussed in my reading/listening. It potentially exposes more than
> cookies to the sniffer of traffic.

What issues with HTTP redirects do you mean?  That's how HTTP
redirects work according to the HTTP specification.

>> 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.
> No. I can build special purpose useragents which will never have these
> vulnerabilities.

We're talking about the protocols as specified.  You can profile HTTP
and the cookie protocol to make them more secure, but that's not how
they work out-of-the-box.

>> > 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.
>    Cookies as a subset of the HTTP protocol share all of the
>    security vulnerabilities of HTTP and in some cases cookie
>    design flaws may excerbate the issues because of the
>    possible leakage of cookie content to unintended servers...
> makes it stronger? or since this is a summary, perhaps stop with
> "excerbate the issues"

I don't think we should be mealy mouthed here.  The protocol is not
well-designed for security.  We should be clear so that folks aren't
confused into creating vulnerable servers.