search

w3c / webappsec-clear-site-data

WebAppSec Clear Site Data
https://w3c.github.io/webappsec-clear-site-data/
Other
19 stars 21 forks source link

Clear a specific cookie #82

Open yoavweiss opened 5 months ago

yoavweiss commented 5 months ago

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 commented 4 months ago

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

johannhof commented 4 months ago

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 commented 4 months ago

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 commented 3 weeks ago

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

stolendata commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

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.