[http-state] Seeking feedback on Security Considerations
Adam Barth <ietf@adambarth.com> Sat, 13 February 2010 08:00 UTC
Return-Path: <adam@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 511E628C16E for <http-state@core3.amsl.com>; Sat, 13 Feb 2010 00:00:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.856
X-Spam-Level:
X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.121, 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 OKUfwoZAdY-l for <http-state@core3.amsl.com>; Sat, 13 Feb 2010 00:00:08 -0800 (PST)
Received: from mail-px0-f178.google.com (mail-px0-f178.google.com [209.85.216.178]) by core3.amsl.com (Postfix) with ESMTP id 9230E28C16D for <http-state@ietf.org>; Sat, 13 Feb 2010 00:00:07 -0800 (PST)
Received: by pxi8 with SMTP id 8so2105346pxi.19 for <http-state@ietf.org>; Sat, 13 Feb 2010 00:01:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.14.3 with SMTP id r3mr1689808rvi.58.1266048088201; Sat, 13 Feb 2010 00:01:28 -0800 (PST)
From: Adam Barth <ietf@adambarth.com>
Date: Sat, 13 Feb 2010 00:01:08 -0800
Message-ID: <7789133a1002130001l6137f704va9e04a4edade1ee7@mail.gmail.com>
To: http-state <http-state@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [http-state] Seeking feedback on Security Considerations
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: Sat, 13 Feb 2010 08:00:09 -0000
The new draft that I've uploaded <http://www.ietf.org/id/draft-ietf-httpstate-cookie-03.txt> contains an updated and expanded Security Considerations section. I've been circulating this section among security experts for feedback. If you have some feedback on this section, I'd like to encourage you to let me know at this time. I've reproduced the Security Considerations section below for your convenience. Thanks, Adam 7. Security Considerations 7.1. General Recommendations The cookie protocol is NOT RECOMMENDED for new applications. For applications that do use the cookie protocol, servers SHOULD NOT rely upon cookies for security. For servers that do use cookies for security, servers SHOULD use a redundant form of authentication, such as HTTP authentication or TLS client certificates. 7.2. Ambient Authority A server that uses cookies to authenticate users can suffer security vulnerabilities because some user agents let remote parties issue HTTP requests from the user agent (e.g., via HTTP redirects and HTML forms). When issuing those requests, user agent attaches cookies even if the entity does not know the contents of the cookies, possibly letting the remote entity exercise authority at an unwary server. User agents can mitigate this issue to some degree by providing APIs for suppressing the Cookie header on outgoing requests. Although this security concern goes by a number of names (e.g., cross-site scripting and cross-site request forgery), the issue stems from cookies being a form of ambient authority. Cookies encourage server operators to separate designation (in the form of URLs) from authorization (in the form of cookies). Disentangling designation and authorization can cause the server and its clients to become confused deputies and undertake undesirable actions. Instead of using cookies for authorization, server operators might wish to consider entangling designation and authorization by treating URLs as object-capabilities. Instead of storing secrets in cookies, this approach stores secrets in URLs, requiring the remote entity to supply the secret itself. Although this approach is not a panacea, judicious use of these principles can lead to more robust security. 7.3. Clear Text Unless sent over a secure channel (such as TLS), the information in the Set-Cookie and Cookie headers is transmitted in the clear. 1. All sensitive information conveyed in these headers is exposed to an eavesdropper. 2. A malicious intermediary could alter the headers as they travel in either direction, with unpredictable results. 3. A malicious client could alter the Cookie header before transmission, with unpredictable results. Servers SHOULD encrypt and sign their cookies when transmitting them to the user agent (even when sending the cookies over a secure channel). However, encrypting and signing cookies does not prevent an attacker from transplanting a cookie from one user agent to another. In addition to encrypting and signing the contents of every cookie, servers that require a higher level of security SHOULD use the cookie protocol only over a secure channel. 7.4. Weak Confidentiality Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server. If a cookie is writable by a service on one port, the cookie is also writable by a service running on another port of the same server. For this reason, servers SHOULD NOT both run mutually distrusting services on different ports of the same host and use cookies to store security- sensitive information. Cookies do not provide isolation by scheme. Although most commonly used with the http and https schemes, the cookies for a given host are also available to other schemes, such as ftp and gopher. This lack of isolation is most easily seen when a user agent retrieves a URI with a gopher scheme via HTTP, but the lack of isolation by scheme is also apparent via non-HTTP APIs that permit access to cookies, such as HTML's document.cookie API. 7.5. Weak Integrity Cookies do not provide integrity guarantees for sibling domains (and their subdomains). For example, consider foo.example.com and bar.example.com. The foo.example.com server can set a cookie with a Domain attribute of ".example.com", and the user agent will include that cookie in HTTP requests to bar.example.com. In the worst case, bar.example.com will be unable to distinguish this cookie from a cookie it set itself. The foo.example.com server might be able to leverage this ability to mount an attack against bar.example.com. Similarly, an active network attacker can inject cookies into the Cookie header sent to https://example.com/ by impersonating a response from http://example.com/ and injecting a Set-Cookie header. The HTTPS server at example.com will be unable to distinguish these cookies from cookies that it set itself in an HTTPS response. An active network attacker might be able to leverage this ability to mount an attack against example.com even if example.com uses HTTPS exclusively. Servers can partially mitigate these attacks by encrypting and signing their cookies. However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic example.com server in the user's session, with unpredictable results. 7.6. Reliance on DNS The cookie protocol relies upon the Domain Name System (DNS) for security. If the DNS is partially or fully compromised, the cookie protocol might fail to provide the security properties required by applications.
- [http-state] Seeking feedback on Security Conside… Adam Barth
- Re: [http-state] Seeking feedback on Security Con… Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [http-state] Seeking feedback on Security Con… Dan Winship
- Re: [http-state] Seeking feedback on Security Con… Adam Barth
- Re: [http-state] Seeking feedback on Security Con… Adam Barth
- Re: [http-state] Seeking feedback on Security Con… Achim Hoffmann
- Re: [http-state] Seeking feedback on Security Con… Achim Hoffmann