Subject: [http-state] Security considerations overview

From: Adam Barth <[email-masked]>
Date: Tue, 2 Mar 2010 11:03:29 -0800

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

---

From: David Morris <[email-masked]>
Date: Tue, 2 Mar 2010 11:42:35 -0800 (PST)

>         compromised by a network attacker.</t>

I don't under stand how the second sentence extends the thought in the 
first sentence. It seems in conflict in the sense that HTTPS is not
sending cookies in the clear and use of HTTPS is generally recommended
as the way to avoid compromise by network hackers. What am I missing?

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Mar 2010 12:05:05 -0800

> as the way to avoid compromise by network hackers. What am I missing?

If even if you use the cookie protocol exclusively over HTTPS, the
default is still to send the cookies in the clear (i.e., the
secure-only-flag defaults to false).

Adam

---

From: David Morris <[email-masked]>
Date: Tue, 2 Mar 2010 13:46:09 -0800 (PST)

> secure-only-flag defaults to false).

But wrapped inside of the HTTPS stream, it is like the remainder of
everything about the HTTP request (including headers), sans any general
HTTPS vulnerabilities, not visible on the network to hackers. 

If you are trying to say that a cookie sent on an HTTPS connection from
a server will be returned on any non-HTTPS connections and hence be
vulnerable in that context, the paragraph doesn't say that. To me it
says that even if my WHOLE application is HTTPS based, the cookies
are vulnerable on the network.

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Mar 2010 13:54:57 -0800

> are vulnerable on the network.

Even if your whole application is HTTPS-based, the cookies are
vulnerabile to active network attackers.  That is a true statement,
and precisely the security problem we're trying to point out in that
sentence.  Maybe this is a better formulation?

[[
        In addition, by default,
        the cookie protocol does not provide confidentiality from network
        attackers.
]]

Adam

---

From: Tyler Close <[email-masked]>
Date: Tue, 2 Mar 2010 14:38:08 -0800

>        the cookie protocol does not provide confidentiality from network

A reader could again misinterpret that formulation and so believe the
problem can be fixed by using HTTPS, which is incorrect.

I think this thread is a good indication that providing an "executive
summary" at the start of the Security section could be very effective
in communicating the rationale behind the prior recommendation against
using cookies in new applications. Succinct statements can sometimes
communicate better than detailed descriptions.

--Tyler

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

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Mar 2010 14:52:01 -0800

> communicate better than detailed descriptions.

Does this help?

[[
        In addition, by default,
        the cookie protocol does not provide confidentiality from network
        attackers, even when used over HTTPS.
]]

Adam

---

From: David Morris <[email-masked]>
Date: Tue, 2 Mar 2010 15:27:32 -0800 (PST)

No. Network attacks that impact HTTPS in general should not be used
to claim that cookies, by default, are not secure. Network infrastructure
manipulation which would reveal totally HTTPS website cookie content would 
also expose everything else about the HTTP based application to intercept,
manipulation, etc. 

I still don't see the actual vulnerability, and haven't yet reviewed
the backing details, but I think that makes me the typical reader of
the summary. If what I read in the summary doesn't make sense, I'll
probably ignore the details.

Furthermore, I suspect these vulnerabilities depend on the specific
User-Agent implemenation. 

The executive summary needs to provide an accurate description of
the issue. I'd try to suggest an alternate set of words, but I don't yet
understand the basis of the claim.

The generic summary statement proposed below applies equally to anything
associated with HTTP. By default the content isn't secure. If that is what 
you mean, than say something like:
   Cookies as a subset of the HTTP protocol share all of the security
   vulnerabilities of HTTP and in some cases may excerbate the 
   issues because of the possible leakage of cookie content to
   unintended servers...

David Morris

On Tue, 2 Mar 2010, Adam Barth wrote:

> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Mar 2010 15:39:13 -0800

> also expose everything else about the HTTP based application to intercept,

We're not talking about vulnerabilities in HTTPS or TLS.  We're
talking about the default behavior of the cookie protocol itself,
which does not provide confidentiality from network attackers.

> probably ignore the details.

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.

> User-Agent implemenation.

No.  The vulnerability is in the design of the protocol.

> understand the basis of the claim.

The issue is described in detail later in the section.

>   issues because of the possible leakage of cookie content to

That summary is insufficiently harsh.  The cookie protocol has a
number of design errors that impair its security far more than the
rest of the HTTP protocol.

Adam

---

From: David Morris <[email-masked]>
Date: Tue, 2 Mar 2010 16:04:45 -0800 (PST)

> 2) The user agent makes a single HTTP request.

That case was excluded by my earlier restriction to all HTTP.

> redirect to http://example.com/.

Only applies if there is an HTTP server on the same host. And it requires
a vulnerable infrastructure at either end of the connection.

This also suggests some issues with HTTP redirect which have not been
discussed in my reading/listening. It potentially exposes more than
cookies to the sniffer of traffic.

> No.  The vulnerability is in the design of the protocol.

No. I can build special purpose useragents which will never have these
vulnerabilities.

> rest of the HTTP protocol.

    Cookies as a subset of the HTTP protocol share all of the
    security vulnerabilities of HTTP and in some cases cookie
    design flaws may excerbate the issues because of the
    possible leakage of cookie content to unintended servers...

makes it stronger? or since this is a summary, perhaps stop with
"excerbate the issues"

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 02 Mar 2010 16:11:55 -0800

> 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?

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 02 Mar 2010 16:14:59 -0800

> That case was excluded by my earlier restriction to all HTTP.

That kind of "all HTTP" restriction, at the UA level rather than the  
site level, is one that you can not count on in a browser or even in  
most kinds of site-specific UAs.

> a vulnerable infrastructure at either end of the connection.

Nope, you can spoof HTTP responses without the need for the targetHTTP  
server to really exist. All it requires is some vulnerable  
infrastructure somewhere.

> cookies to the sniffer of traffic.

HTTP traffic, since it is sent in the clear, obviously provides  
neither confidentiality nor integrity. What is non-obvious is that  
cookies by default make some of this built-in vulnerability leak over  
to affect HTTPS.

Regards,
Maciej

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Mar 2010 16:14:30 -0800

On Tue, Mar 2, 2010 at 4:11 PM, Maciej Stachowiak <[email-masked]> wrote:
> 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

---

From: Adam Barth <[email-masked]>
Date: Tue, 2 Mar 2010 16:15:22 -0800

> That case was excluded by my earlier restriction to all HTTP.

Even if a web server operates exclusively over HTTPS, general purpose
user agents are willing to issue HTTP requests.

> a vulnerable infrastructure at either end of the connection.

We're discussing a network attacker.  A network attacker can spoof an
HTTP response from a host even if that host is not operating an HTTP
server.  Likewise, a network attacker can intercept an HTTP request to
a host even if that host is not operating an HTTP server.

> cookies to the sniffer of traffic.

What issues with HTTP redirects do you mean?  That's how HTTP
redirects work according to the HTTP specification.

> No. I can build special purpose useragents which will never have these

We're talking about the protocols as specified.  You can profile HTTP
and the cookie protocol to make them more secure, but that's not how
they work out-of-the-box.

> makes it stronger? or since this is a summary, perhaps stop with

I don't think we should be mealy mouthed here.  The protocol is not
well-designed for security.  We should be clear so that folks aren't
confused into creating vulnerable servers.

Adam

---

From: Tyler Close <[email-masked]>
Date: Tue, 2 Mar 2010 16:40:26 -0800

> 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

---

From: Achim Hoffmann <[email-masked]>
Date: Wed, 03 Mar 2010 02:09:53 +0100

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

---

From: Achim Hoffmann <[email-masked]>
Date: Wed, 03 Mar 2010 02:17:38 +0100

>    this is inherit of the used transport layer protection (such as TLS)

outch,  s/inherit/independent/

---

From: Mark Pauley <[email-masked]>
Date: Wed, 3 Mar 2010 15:32:00 -0800

Excuse my ignorance, I've just recently joined this list.

Is this the correct forum to enquire about what we refer to as the 'Cross Site Acceptance Policy'?  We (Safari / CFNetwork) by default refuse to set cookies from hosts from a domain tree outside of the current Top Level Domain tree.  That is from a host with name x1.x2.x3...x_k  we'll set a cookie with domain .y1.y2.y3...y_m if and only if y_m == x_k, y_m-1 == x_k-1, etc to y_m-n == x_k-n and y1....y_m-n is not a top level domain.  

That is, if the domain is at least a cousin; the target domain shares a common ancestor with the origin domain which is not a Top Level Domain.

We've worked out that this is probably the most restrictive definition that will work given a good enough description of what a Top Level Domain is (which we have thanks to the Mozilla Top Level Domain list project).

---

From: Mark Pauley <[email-masked]>
Date: Wed, 3 Mar 2010 15:38:19 -0800

It would appear that this is covered by 4.1.2.2

We (and many other browsers) do allow setting a cookie with domain .bar.example.com from .foo.example.com

Indeed, some web applications rely on this behavior.  The compromise is that we'll allow .foo.example.com to set a cookie for .bar.example.com if and only if .example.com is not a Top Level (or registry controlled) Domain.

---

From: Achim Hoffmann <[email-masked]>
Date: Thu, 04 Mar 2010 09:55:45 +0100

> Indeed, some web applications rely on this behavior.  The compromise is that we'll allow .foo.example.com to set a cookie for .bar.example.com if and only if .example.com is not a Top Level (or reg…

outch.
That's exactly why 7. Security Consideration writes:

   Cookie protocol is NOT RECOMMENDED for (new) applications.

(my personal opinion for *secure* applications would be: FORBIDDEN ;-)
Achim

---

From: Adam Barth <[email-masked]>
Date: Thu, 4 Mar 2010 05:33:38 -0800

> (my personal opinion for *secure* applications would be: FORBIDDEN ;-)

FWIW, that section doesn't say that anymore.

Adam

---

From: Mark Pauley <[email-masked]>
Date: Thu, 4 Mar 2010 11:25:34 -0800

Sorry, this was confusion on my part, we cleared this up.  We (CFNetwork / Safari) don't allow sibling domains to be set via cookies.  We do restrict the hosts that can set cookies based on the 'Main Document' URL.  A response from a request for a sub-resource is considered not a 3rd-party response if it came from a host that shares a non- top level domain postfix with the Main Document URL's host.  

So we won't let you set .bar.example.com from foo.example.com, but we will let you set .example.com from foo.example.com, which of course can cause a race where bar.example.com thinks it's got a valid session.

My confusion is that if you load foo.example.com, which has an embedded image loaded from www.advertisement.com, we will fail to set any cookies in the response for the request for that image.  This is of course only for the default 'Do not allow 3rd party cookies' setting.

---

From: David Morris <[email-masked]>
Date: Thu, 4 Mar 2010 12:40:40 -0800 (PST)

On Thu, 4 Mar 2010, Mark Pauley wrote:

> My confusion is that if you load foo.example.com, which has an embedded
> image loaded from www.advertisement.com, we will fail to set any cookies

This nitpicky ... but 'will fail to set' should read 'will not set' as the
first implies an error and the later implies intended behavior.