Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSP: Allow precise control of cookies #561

Open
sindastra opened this issue Dec 22, 2019 · 5 comments
Open

CSP: Allow precise control of cookies #561

sindastra opened this issue Dec 22, 2019 · 5 comments

Comments

@sindastra
Copy link

sindastra commented Dec 22, 2019

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
Copy link

hiburn8 commented Jun 18, 2020

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:

  • Subdomains and paths which have user-hosted content. You dont want user1.example.com to be able to set a cookie for user2.example.com. Or example.com/user1 to set cookies for example.com/user2
  • Being able to block cookies for the sake of privacy/tracking.
  • Being able to block cookies from storing unnecessary data (for example, stored XSS via a cookie or tainting existing cookies).

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
Copy link
Member

dveditz commented Jun 22, 2020

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
Copy link

Malvoz commented Jun 22, 2020

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
Copy link
Author

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants