Re: Adding cookie scope to CSP

On Fri, Sep 13, 2013 at 7:57 PM, Trevor Perrin <trevp@trevp.net> wrote:
> On Fri, Sep 13, 2013 at 4:47 PM, Nottingham, Mark <mnotting@akamai.com> wrote:
>> I don't see how CSP is competitive to those more ambitious approaches.


I see this CSP proposal to expressing limits on cookie behavior as
being complementary to some of the other approaches.  It may also have
the possibility to solve problems that are not addressed by the other
approaches.  It can also provide a level of defense-in-depth
in-support of other approaches, which seems to be one of the main
areas where CSP is most valuable.  In particular, a frustrating aspect
of cookies today is that they follow a different set of rules than one
might expect from Origin policies.  While this is necessary, there are
cases where being able to limit cookies set by content to obey origin
policies would be highly valuable.

The concrete case where CSP-based cookie limiting may be most valuable
is where web server infrastructure is operated independently of the
web content being served via that infrastructure, and where multiple
virtual hosts exists within a single domain.  This is becoming fairly
common with a number of PaaS and IaaS environments.  The github case
mentioned in Mark's original email was one good example. There are
some other vulnerability classes that can only be solved if there is
some way for the operator of a domain (eg, example.com) to be able to
serve content on many subdomains of example.com but be able to limit
where the served content can set cookies.

Being able to return a header limiting the cookie scope allowed for
content enables a limitation to be placed on what that content can do
without the need to fully control or inspect the content.  This
doesn't close off all vulnerabilities (such as in the case of DNS
poisoning or MitM attacks), but it does help with the much worse case
that a single piece of globally accessible hostile content can attack
an entire domain.

A few of the domains that have been impacted by this in the past
appear to be adding themselves to the Public Suffix List (PSL) to
prevent some browsers from setting cookies on those domains.  It feels
like CSP is a better and more scalable way to achieve the intended
goal, at least for some of these domains.  (In addition, many of the
same domains also need to have wildcard SSL certificates covering the
domain, and this quickly gets ambiguous if SSL and cookies both want
to impose limitations using a single PSL.)

 On top of Mark's proposal below, it may be worth providing three additions:

1) Add an additional cookie-scope directive-value of "none" that
prevents content
   from setting cookies entirely.  This could be valuable for hosts or
domains that
   should never have cookies be set, and could also be valuable when serving
   purely user-generated content.

2) Add an additional cookie-scope directive-value of "path" that is stricter
   than "host" and additionally prevents setting cookies
   on less-specific paths than the current URI-path.  For Section 5.2
   of [RFC6265], when a user-agent is processing a cookie set by content
   and directive-value="path", either cookie-attribute-list
   must not have a "Path" element or cookie's path must be
   more specific than the path of the request-uri.

3) Add additional cookie-scope directive-values of "sub-origin" and
"origin" that
    limit cookies what cookies can be set to the Origin or Sub-Origin.


An alternative mechanism to this would be to allow the header to
explicitly express
a URI path to limit cookie scope to in addition to any rules already
being applied.
For example:

    directive-name   = "cookie-scope-prefix"
    directive-value  = uri

So you might have:

    Content-Security-Policy: cookie-scope-prefix=http://www.example.com/~alice/
    Content-Security-Policy: cookie-scope-prefix=http://www.example.com/

There may be some other mechanisms in-between these.  It's likely a
matter of trying
to find a balance between flexibility and complexity.  My inclination
is that using Mark's
approach with directive-values covering the common use-cases may be a
good compromise, such as:

  directive-name   = "cookie-scope"
  directive-value  = "none" / "host" / "domain" / "origin" / "sub-origin"

(It feels like if we want to go down a path restriction approach, it
may make more
sense to encapsulate the semantics of that under sub-origin rules
rather than trying
to replicate that here.)

       Erik





> > ---8<---
> >
> > cookie-scope
> >
> > The cookie-scope directive restricts the allowable domain(s) for cookies
> > [RFC6265] set by content. The syntax for the name and value of the directive
> > are described by the following ABNF grammar:
> >
> > directive-name   = "cookie-scope"
> > directive-value  = "host" / "domain"
> >
> > Let cookie be the result of step 6 in the algorithm described by Section 5.3 of
> > [RFC6265], when a user-agent is processing a cookie set by content.
> >
> > When the directive-value is "host", and the cookie's host-only-flag is false,
> > the user-agent MUST ignore the cookie entirely and abort the algorithm.
> >
> > Otherwise, the algorithm is continued.
> >
> > Usage
> >
> > This section is non-normative.
> >
> > Cookies can be set across different hosts in a domain; for example,
> > login.example.com can set a cookie that's visible to sports.example.com. While
> > this is useful when these different hostnames are under the control of one
> > party, it is problematic when a site uses hosts in the same domain for
> > "user-generated" content; e.g., bob.example.net and alice.example.net.
> >
> > While hosts of such sites can control what cookies are set with HTTP headers by
> > filtering them, it is more difficult to do so for those cookies set by content.
> >
> > The cookie-scope directive allows these sites to control the cookies set by
> > content, limiting them to a single host where appropriate:
> >
> > Content-Security-Policy: cookie-scope=host
> >
> > --->8---

Received on Monday, 16 September 2013 14:36:31 UTC