W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2018

RE: [CSP3] Suggestion for COOKIE directive

From: <michael.oneill@baycloud.com>
Date: Thu, 25 Oct 2018 14:39:14 +0200
To: "'Daniel Veditz'" <dveditz@mozilla.com>, <mattrq@gmail.com>
Cc: "'WebAppSec WG'" <public-webappsec@w3.org>
Message-ID: <015501d46c5f$be4e1c30$3aea5490$@baycloud.com>
First-party sites can now delete, or decide not to use, their own cookies but there is no way to communicate user consent to embedded resources. In Europe sites are required to take responsibility for this. Without script or third-party access to other origin cookies, and without wider support for the DNT consent API in user agents, sites would have to dynamically edit resource src/href etc. attributes or use some complex error-prone and latency increasing mechanism based on postMessage, to communicate consent. Even if consent can be communicated there may be embeddees that ignore it or have buggy implementations etc. This leads to even further loss in trust for the web platform and the ecosystem.

 

We have CSP directives that can block resources, sandbox iframes etc. but not “sandbox” other resources. This suggestion deals with that gap, and I support it.

 

Presumably the cookie-src directive would have a source list of domains that would be able to access cookies, i.e. as per the usual CSP rules once the directive exists the source list is a whitelist.

 

I agree localStorage etc. should also be covered so I would ask that the directive be renamed storage-src to describe the wider scope.

 

Mike O’Neill

 

 

 

From: Daniel Veditz <dveditz@mozilla.com> 
Sent: 24 October 2018 22:16
To: mattrq@gmail.com
Cc: WebAppSec WG <public-webappsec@w3.org>
Subject: Re: [CSP3] Suggestion for COOKIE directive

 

On Wed, Oct 24, 2018 at 3:25 PM Matt Rosenquist <mattrq@gmail.com <mailto:mattrq@gmail.com> > wrote:

> I would like to suggest a set of new directives for the content security

> policy which would allow the site to limit access to cookies. 

 

What do you mean by "access to cookies"? Are you talking about scripted access to document.cookies, HTTP cookie headers, or both?

 

Can you give concrete examples of security problems or concerns sites have today that this new control would resolve?

 

What hacky workarounds are sites having to do to mitigate these problems in the meantime?

 

What will sites have to do in a world where some browsers support this and some don't yet? Would these old hacky workarounds coexist with the CSP control so that sites don't have to choose between being unsafe in older browsers or broken content in newer browsers?

 

> This may be is three forms (first being the most important):
> - cookie-src (read/write)

 

This is already the default web behavior so it would seem least important (just don't specify a cookie directive).

 

-Dan Veditz
Received on Thursday, 25 October 2018 12:39:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 25 October 2018 12:39:39 UTC