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

Clear a specific cookie #82

Open
yoavweiss opened this issue Jun 18, 2024 · 7 comments
Open

Clear a specific cookie #82

yoavweiss opened this issue Jun 18, 2024 · 7 comments

Comments

@yoavweiss
Copy link

Over the years, large sites and platform can accumulate "cookie cruft" - cookies that they observe coming from users, but ones that are no longer actively used and don't exist in their current codebase.

Deleting such cookies is possible by setting their expiry date to one in the past. At the same time, in order to do that, one needs to know the "domain" and "path" parameters with which they were set, which is not something that can be passively observed on the server side.

It'd be useful to have a way to clear specific cookie names regardless of their path and domain.

/cc @colinbendell

@annevk
Copy link
Member

annevk commented Jul 9, 2024

I think this use case makes sense, but we should probably standardize this in the IETF. E.g., Delete-Cookie: name1, name2.

@johannhof
Copy link
Member

FYI @DCtheTall @sbingler

I think this could be useful, I wonder if there are any Privacy / Security considerations from clearing individual cookies without knowing their domain / path (effectively being able to override these cookies), but alas this seems already possible with CSD? (cc @arturjanc, @ddworken)

@arturjanc
Copy link

I'm fairly sure that being able to clear / override individual cookies is already a capability that exists in the platform. If you control an arbitrary HTTP header on a sibling subdomain you'll generally be able to overflow the parent domain's cookie jar and remove or overwrite arbitrary cookies. So I don't think that adding this as an explicit capability would open applications up to any new risks.

@yoavweiss
Copy link
Author

I sent an email to the IETF HTTPWG to suggest that. Thanks all! :)

@stolendata
Copy link

With this feature a parent host will also be able to arbitrarily nullify legitimate site preferences and even login cookies belonging to, for example, end-users of customers who reside on the parent host's subdomains. Is such an attack somehow also "useful to have"?

In my head I imagine this being the keyboard that was used when dreaming up the whole proposal: https://vid.pr0gramm.com/2024/10/31/3dea286383213d68.mp4

@yoavweiss
Copy link
Author

With this feature a parent host will also be able to arbitrarily nullify legitimate site preferences and even login cookies belonging to, for example, end-users of customers who reside on the parent host's subdomains. Is such an attack somehow also "useful to have"?

Can you illustrate the scenario with a concrete example?

Otherwise, please maintain a respectful tone, as this repo is subject to the W3C's Code of Conduct.

@annevk
Copy link
Member

annevk commented Nov 5, 2024

The server that can set the Delete-Cookie header can also set the Set-Cookie header with an expiry time in the past. What Delete-Cookie brings to the table is that there's no need to match the Path and some other attributes, but those are not a security boundary. So yes, this means that certain cookies can be deleted across the domain boundary (but within a site), but those could already be deleted using the Set-Cookie header anyway.

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