Re: [http-state] Security considerations overview

Tyler Close <tyler.close@gmail.com> Wed, 03 March 2010 00:40 UTC

Return-Path: <tyler.close@gmail.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 919BF3A7D1B for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 FqiOPYhc3PEp for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:40:27 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id B8A3D3A6D3F for <http-state@ietf.org>; Tue, 2 Mar 2010 16:40:27 -0800 (PST)
Received: by pwi3 with SMTP id 3so557418pwi.31 for <http-state@ietf.org>; Tue, 02 Mar 2010 16:40:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w0FgnKKGcKp9oPIWMlzTtgiG8fTyJfSNOOC7IIYxkOg=; b=GCQGJsN4A8ibo4WFNCW2v/7bwwvDJkiF9Wqa4vW1bOdh65nSMmKy57CCiydPLosv13 p5kKAtqhSViW5xsqibnFoNPQxJgHdj3VAuVENXu+YeZBeDL1TtGnXlcN0hUJFz7EnrEZ 5tSFTC+wXSEkt+FzFDtn3Q6MiSxmabH4+I63I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BOWJ2Qu+ps/SXfJIXI5c0lAgV9uwVnH1hlh8FHjrPJHngyH53Lt6YVngdtoegP7pVT nACk9nSz0OjUm+Fbjp4CaSP+r3N6fa4oJFvGe+5tdzch9FEzqjwI0erLBC6Lmq+BOlUy ibup0lAyDMetCzmuH1q0CpxGB38G3IVnM3nOs=
MIME-Version: 1.0
Received: by 10.140.248.18 with SMTP id v18mr428815rvh.148.1267576826149; Tue, 02 Mar 2010 16:40:26 -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>
Date: Tue, 2 Mar 2010 16:40:26 -0800
Message-ID: <5691356f1003021640n22c2dc49j7939a2f4d19d1868@mail.gmail.com>
From: Tyler Close <tyler.close@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:40:28 -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.)
>
> 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?

According to section 4.1.2, the cookie store *only* takes into account
the cookie-name, domain-value, and path-value when overwriting a
cookie. So an active network attacker could overwrite a "Secure"
cookie by specifying a Set-Cookie: header in a forged plain HTTP
response. As Adam indicated, if the user-agent makes a plain HTTP
request to *any* domain, the active network attacker can turn that
request into a request to the victim domain by forging a redirect
response. The malicious Set-Cookie header is specified in response to
the redirected request.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html