Re: Adding cookie scope to CSP

On Tue, Sep 17, 2013 at 10:41 AM, Erik Nygren <erik+w3@nygren.org> wrote:
> Having the webserver ignore untrusted cookies is also not adequate.
> Some of the things we want to protect against (not a complete list):
>
> 1) Content on one host setting a cookie that gets sent for every HTTP
> request to the domain:
> 1a) Performance or availability issues across hosts in the domain if
> the number of cookies set gets to be too big (as cookies set on the
> domain are sent to all hosts in the domain, including hosts that don't
> want to get those cookies).
> 1b) Potential privacy or compliance issues caused by this.  (Content
> from host in the domain can cause cookies to be sent with information
> that other hosts in the domain may not want to see from a
> privacy/compliance perspective.)
> 1c) Potential attack vectors against other websites in the domain (eg,
> enabling CSRF attacks against some types of buggy software)
>
> 2) Content on one host deleting or modifying cookies set on the domain.


Mark has a good point that "origin cookies" or similar would require
the web app to modify its session management.

I also agree with your points (1a) and (1c) - "origin cookies"
wouldn't prevent a malicious subdomain from setting lots of large
cookies to slow down the user experience, nor prevent cookies being
used to trigger vulnerabilities in older apps.

I do think they'd solve (1b) and (2), however:
 (1b): a malicious subdomain could only leak its own private data - so
not an issue
 (2): a malicious subdomain couldn't delete or modify origin cookies
set on the domain

That said, I think (1a) and (1c) are fairly minor issues, and can be
better dealt with other ways:
 (1a) - Browsers should enforce reasonable limits on size / number of cookies
      - Upon receiving large unexpected cookies, a webserver could delete them
 (1c) - Web apps with exploitable cookie handling should be fixed

I concede a CSP policy could have "defense-in-depth" value against
these, and could be used by web apps unwilling to modify their session
management.

But the major "cookie-scoping problems" are the confidentiality and
integrity issues, e.g. [1].  And I think these are better solved by
something like "origin cookies", since that would resist a wider range
of attacks (malicious webservers or MITM, not just malicious
javascript).  Also it's more reliable, as the policy would be declared
once when the cookie is set, instead of needing it declared to
"blacklist" every possible malicious javascript in the domain.

So I still encourage people to consider some of the websec proposals,
and help us push those forward.


Trevor


[1] http://www.ietf.org/mail-archive/web/websec/current/msg01719.html

Received on Wednesday, 18 September 2013 06:30:57 UTC