Re: [http-state] Security considerations overview

Adam Barth <ietf@adambarth.com> Wed, 03 March 2010 00:15 UTC

Return-Path: <ietf@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 29B1B3A8D04 for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 iVVfK2-bochl for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:15:03 -0800 (PST)
Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by core3.amsl.com (Postfix) with ESMTP id D14983A887E for <http-state@ietf.org>; Tue, 2 Mar 2010 16:14:59 -0800 (PST)
Received: by gxk3 with SMTP id 3so259076gxk.13 for <http-state@ietf.org>; Tue, 02 Mar 2010 16:14:57 -0800 (PST)
Received: by 10.150.116.11 with SMTP id o11mr350977ybc.144.1267575291700; Tue, 02 Mar 2010 16:14:51 -0800 (PST)
Received: from mail-iw0-f179.google.com (mail-iw0-f179.google.com [209.85.223.179]) by mx.google.com with ESMTPS id 23sm4617514iwn.14.2010.03.02.16.14.50 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Mar 2010 16:14:50 -0800 (PST)
Received: by iwn9 with SMTP id 9so916557iwn.17 for <http-state@ietf.org>; Tue, 02 Mar 2010 16:14:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.160.205 with SMTP id o13mr361171ibx.13.1267575290171; Tue, 02 Mar 2010 16:14:50 -0800 (PST)
In-Reply-To: <D88C1747-4C28-43DB-9BBD-5EB951CCD471@apple.com>
References: <5c4444771003021103s422a65c3me96af57dfee58105@mail.gmail.com> <Pine.LNX.4.64.1003021139330.4097@egate.xpasc.com> <5c4444771003021205t78c18f73t78913ae6ff3c70b1@mail.gmail.com> <Pine.LNX.4.64.1003021337130.21569@egate.xpasc.com> <5c4444771003021354o70faccache31b8a0d28005aeb@mail.gmail.com> <5691356f1003021438t1487d6d0g39439a2bdc3543ce@mail.gmail.com> <5c4444771003021452g44538236ta855abcfe6d578da@mail.gmail.com> <Pine.LNX.4.64.1003021508100.21569@egate.xpasc.com> <5c4444771003021539i2ed4ea44mf6b52970bc52385b@mail.gmail.com> <D88C1747-4C28-43DB-9BBD-5EB951CCD471@apple.com>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 2 Mar 2010 16:14:30 -0800
Message-ID: <5c4444771003021614wbdbc35g8576ce2242039dbe@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Security considerations overview
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: Wed, 03 Mar 2010 00:15:05 -0000

On Tue, Mar 2, 2010 at 4:11 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Mar 2, 2010, at 3:39 PM, Adam Barth wrote:
>> The issue is quite simple:
>>
>> 1) In an HTTPS response, the example.com 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 http://example.com/.
>> 4) The user agent follows the redirect and sends the cookie foo in the
>> clear, where it can be observed by the attacker.
>
> Sounds like attacker can violate the integrity, as well as confidentiality,
> of non-Secure cookies this way (i.e. they could spoof the non-SSL response
> and set the cookie to the value of their choice.)

Yes.

> Can this type of attack also affect the integrity of Secure cookies, or is
> there something to prevent them from being overwritten from non-SSL?

The cookie protocol provides zero integrity protection from network
attackers.  See paragraph 3 of
http://tools.ietf.org/html/draft-ietf-httpstate-cookie-04#section-7.6

Adam