Re: [http-state] Security considerations overview

Achim Hoffmann <ah@securenet.de> Wed, 03 March 2010 01:09 UTC

Return-Path: <ah@securenet.de>
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 811B73A8CBB for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 17:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.658
X-Spam-Level:
X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_OBFU_VALUE=0.525]
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 VaVJVng+CvWp for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 17:09:57 -0800 (PST)
Received: from munich.securenet.de (munich.securenet.de [82.135.17.200]) by core3.amsl.com (Postfix) with ESMTP id 76A3D3A8BF8 for <http-state@ietf.org>; Tue, 2 Mar 2010 17:09:57 -0800 (PST)
Received: from oxee.securenet.de (unknown [10.30.18.40]) by munich.securenet.de (Postfix) with ESMTP id 980E827192 for <http-state@ietf.org>; Wed, 3 Mar 2010 02:09:57 +0100 (CET)
Received: by oxee.securenet.de (Postfix, from userid 65534) id 8296E140202A; Wed, 3 Mar 2010 02:09:57 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by oxee.securenet.de (Postfix) with ESMTP id B61361402027; Wed, 3 Mar 2010 02:09:56 +0100 (CET)
Received: from oxee.securenet.de ([127.0.0.1]) by localhost (oxee.securenet.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12032-01; Wed, 3 Mar 2010 02:09:56 +0100 (CET)
Received: from nemo.home.ah (ah.vpn.securenet.de [172.16.18.33]) by oxee.securenet.de (Postfix) with ESMTP id A1F8C1402426; Wed, 3 Mar 2010 02:09:55 +0100 (CET)
Message-ID: <4B8DB6E1.4030805@securenet.de>
Date: Wed, 03 Mar 2010 02:09:53 +0100
From: Achim Hoffmann <ah@securenet.de>
User-Agent: who">cares?
MIME-Version: 1.0
To: http-state@ietf.org
References: <5c4444771003021103s422a65c3me96af57dfee58105@mail.gmail.com>
In-Reply-To: <5c4444771003021103s422a65c3me96af57dfee58105@mail.gmail.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Open-Xchange Express amavisd-new at oxee.securenet.de
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 01:09:58 -0000

After reading all the comments about "cookie protocol is secure or not
with https", I'd through in following:

   the (current) cookie protocol has no integrity and no confidentiality
   this is inherit of the used transport layer protection (such as TLS)

I.g. we can totally omit the transport layer as the cookie is subject to
the same threats there as all other HTTP data too.

But what's different for cookies compared to most other HTTP headers?
The cookie is accessable in the client. That's where it can be modified.
The most common vulnerability and attack is XSS. XSS is independent of
client implemetation and may be impossible to detect there.
In the client the cookie is unencrypted, wether it was transported with
https or not. That's what Adam describes.
Conclusion: https is not a protection for the integrity of the cookie.
Proper encrypted cookie vallues would solve the issue.
Sending cookies received with htpps ober http lines is just another,
additional, posibility.
Look at the WWW-Authentication header which does not suffer from these
problems.

Does this explain the problem and the necesssity of a specific security
comment for cookies?

Achim


Adam Barth schrieb:
> Rather than have a blanked "cookies are bad" statement at the
> beginning of the security considerations section, Tyler suggested that
> we overview the main security issues with cookie (of course, providing
> details later in the section).  Here's a first draft of an overview
> section.
> 
>       <section anchor="section-overview" title="Overview">
>         <t>The cookie protocol has a number of security and privacy
>         pitfalls.</t>
> 
>         <t>In particular, cookies encourage developers to rely on ambient
>         authority for authentication, often creating vulnerabilities such as
>         cross-site request forgery.  When storing session identifiers in
>         cookies, developers often create session fixation
>         vulnerabilities.</t>
> 
>         <t>Transport-layer encryption, such as HTTPS, is insufficient to
>         prevent a network attacker from altering a victim's cookies because
>         the cookie protocol does not provide integrity.  By default, cookies
>         are transmitted in the clear, where their confidentiality can be
>         compromised by a network attacker.</t>
>       </section>
> 
> Adam