search

w3c / webappsec

Web Application Security Working Group repo
https://www.w3.org/groups/wg/webappsec/
Other
607 stars 148 forks source link

CSP: Allow precise control of cookies #561

Open sindastra opened 4 years ago

sindastra commented 4 years ago

Suggestion: Create two cookie scopes, one that controls HTTP cookies and one that controls JavaScript cookies and use the same syntax as resource loading. An example could be:

cookie-scope-js: 'none'
cookie-scope-http: 'self' https://*.example.com

Or even add cookie-scope-active to control any form of active content that could set cookies (i.e. JS and other non-HTTP cookies), if applicable.

An example could be:

cookie-scope-active: 'none'
cookie-scope-js: 'self'
cookie-scope-http: 'self' https://*.example.com

Which would allow for precise control which domains/protocols may set which kind of cookies.

hiburn8 commented 4 years ago

This is really interesting. I dont know if this concept has been discussed further beyond this? (i can see a lot of stuff prior that seems to have dwindled).

Off the top of my head, there are 3 cookie security 'issues' i can think of you might want to control via CSP:

Depending on what you want to tackle with cookies in CSP, i guess it makes sense for the control to look slightly different. For example, if you just want an ON/OFF toggle for cookies, I think maybe Feature-Policy is a better place? or even Sandbox. If you want more granular control, I like your proposal. And if you are coming from the privacy/bad-data storage angle, then presumably other browser features like LocalStorage and Cache would need to be considered too. In-fact, these technologies also impact the 'user has their own subdomain/path'-type applications also.

I guess the complexity of deciding what is needed from a CSP cookie control, is the reason we dont have one.

dveditz commented 4 years ago

This proposal is too vague to be actionable in its current form. It might be more fruitful to flesh it out in conversation on our working group's mailing list first.

A related (but orthogonal) proposal is the Storage Access API which assumes at least some 3rd party document contexts (e.g. iframes) have their cookie and other storage capabilities blocked by default and provides a mechanism for those contexts to request permission.

Javascript access to cookies is already somewhat controlled by the ability to set the "HttpOnly" property on cookies. That leaves out other storage types, though, and also doesn't prevent a JS context from creating new cookies without the HttpOnly flag.

As a user I know why I'd like to limit 3rd party storage access, and several browsers are implementing different tracking protection schemes for that. But this proposal is for functionality that would be used by web sites. Do we have any concrete examples of web site developers wanting to use this kind of functionality? They trust a 3rd party enough to want to include their assets, but don't want to allow cookies?

Malvoz commented 4 years ago

Do we have any concrete examples of web site developers wanting to use this kind of functionality?

You might find concrete examples, or at least a few (perhaps different) use cases here and here.

sindastra commented 4 years ago

I needed this functionality as I was writing some rules and saw it didn’t exist so I opened this issue here. I don’t remember from the top of my head what it was for but generally speaking there’s nothing wrong with being able to “harden” your permissions.

One aspect could be GDPR and the cookie law where you as a website developer want to make sure only allowed resources can place a cookie (to avoid accidental, non declared cookies to be set).

If I remember what I specifically needed it for in the past, I’ll add the specific example. But there are a few things I can imagine it being used for and by default I don’t trust anything and wouldn’t recommend anyone to go by trust which is why CSP exists in the first place.

mikkorantalainen commented 4 years ago

Any progress here? Considering EU Court ruling in Case C-40/17 (http://curia.europa.eu/juris/liste.jsf?num=C-40/17) and especially paragraphs 55-58 it seems that enforcing cookie restrictions with CSP might be worth the trouble to reduce your risk with violating GDPR due 3rd party setting cookies. If one had defined that Facebook cannot set new cookies in that case, there would not have been violation, as far as I can see.

In that specific case, for the "Like" button feature to work as intended, it would have still required read access to already set Facebook cookies, though. I think that in most cases (when it comes to GDPR) you would like to enforce any 3rd party cookies as read-only or maybe deny-create so that existing customers of 3rd party could continue using already established 3rd party services but new visitors cannot be forced to eat cookies of any new 3rd party.

Full ruling in English here: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:62017CJ0040&from=EN