Subject: [http-state] Seeking feedback on Security Considerations

From: Adam Barth <[email-masked]>
Date: Sat, 13 Feb 2010 00:01:08 -0800

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.

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 13 Feb 2010 11:48:56 +0100

>    that cookie in HTTP requests to bar.example.com.

A bar.example.com can also overwrite a ".example.com" cookie set by  
foo.example.com. Maybe that should be mentioned?

Another possible issues that maybe should be mentioned is that in shared  
hosting environments where multiple independent services are hosted in the  
same domain or on the same server it is possible for a malicious service  
to interfere with other services by setting cookies for domains and paths  
that will get them sent to other services.

Should the fact that clients also support cookies through HTML meta tags  
and the Javascript document.cookie API be mentioned? The latter could be a  
concern when including external Javascripts directly into a HTML document.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Dan Winship <[email-masked]>
Date: Sat, 13 Feb 2010 09:39:10 -0500

>    protocol only over a secure channel.

Should probably mention the problem of having to explicitly set the
"Secure" flag too.

>    Cookies do not provide isolation by port. 
>    Cookies do not provide isolation by scheme.

Also path.

>    Although most commonly
>    are also available to other schemes, such as ftp and gopher.

Do we know that this is consistent across browsers? Should have some
tests for that. If it's not, we can just change "are also available" to
"may also be available" though.

>    This

I think retrieving an HTML+javascript page via ftp is about a zillion
times more "easily seen" than anything involving gopher. :)

-- Dan

---

From: Adam Barth <[email-masked]>
Date: Sun, 14 Feb 2010 10:46:45 -0800

On Sat, Feb 13, 2010 at 2:48 AM, Yngve N. Pettersen (Developer Opera
> foo.example.com. Maybe that should be mentioned?

Done.

> same domain or on the same server it is possible for a malicious service to
> interfere with other services by setting cookies for domains and paths that
> will get them sent to other services.

Indeed.  I've added this paragraph:

[[
        <t>Even though the cookie protocol supports the Path attribute, the
        Path attribute does not provide any integrity protection because the
        user agent with accept an arbitrary Path attribute in a Set-Cookie
        header. For example, an HTTP response to a request for
        http://example.com/foo/bar can set a cookie with a Path attribute of
        "/qux". Consequently, servers SHOULD NOT both run mutually distrusting
        services on different paths of the same host and use cookies store
        security sensitive information.</t>
]]

> Should the fact that clients also support cookies through HTML meta tags and
> the Javascript document.cookie API be mentioned? The latter could be a

Hum...  Maybe we should add a new section about interactions with non-HTTP APIs?

Adam

---

From: Adam Barth <[email-masked]>
Date: Sun, 14 Feb 2010 11:06:28 -0800

> Should probably mention the problem of having to explicitly set the

Haha, indeed.

>>    Cookies do not provide isolation by scheme.

This is slightly more subtle than the other cases because the
confidentiality problems have to do with other user agent
functionality rather than the cookie protocol itself:

[[
        <t>Cookies do not always provide isolation by path. Although the
        network-level protocol does not send cookie stored for one path to
        another, some user agents expose cookies via non-HTTP APIs, such as
        HTML's document.cookie. Because some of these user agents (e.g., web
        browsers) do not isolate resources received from different paths, a
        resource retrieved from one path might be able to access cookies
        stored for another path.</t>
]]

Note that I've also added a paragraph under "integrity" about the
integrity problems w.r.t. path (and these problems are inherent in the
protocol itself):

[[

> Do we know that this is consistent across browsers?

I think so, but I haven't tested it rigorously.

> Should have some tests for that.

Yeah, but we don't have a good harness for non-HTTP tests yet.

> If it's not, we can just change "are also available" to

Done.

> times more "easily seen" than anything involving gopher. :)

Haha, yeah.  I just meant that the problem exists in the protocol
itself and not just in HTML user agents.  I've reversed the order here
to give the more normal example before the pedantic example.

Adam

---

From: Achim Hoffmann <[email-masked]>
Date: Sun, 28 Feb 2010 13:22:38 +0100

Silly question about the used terms (sse partial quote below also):

  Sometimes the text refers to "application", sometimes to "server".

Currently cookies, in particular the cookie protocol, are handled mainly
by servers, but the cookie and its value (key-value pair) are used by
the application (or the framework there). And the application is where
all the secrity issues occour!

Without going into the precise definition where technically the server
ends and the application begins, I'd recommend that these two terms are
used interchangable. Should be mentioned somewhere.

Does this make sense?
Achim

---

From: Achim Hoffmann <[email-masked]>
Date: Sun, 28 Feb 2010 13:38:02 +0100

> Hum...  Maybe we should add a new section about interactions with non-HTTP APIs?

It's partially coverd in the 7.5. Weak Confidentiality section.
I'm aware of at least following non-HTTP issues:
  * meta tag in the message body (HTML)
  * client API (in particular browser access to HTTP headers and DOM)
  * servers/framworks using URL rewriting (it's HTTP, but not the protocol itself)
  * server log files
  * permanent cookie store on the client

Achim