Re: Delete-Cookie header??

well the thing is it does introduce new functionality as a parent domain
may/ any other domain attempt to delete any other domain cookie in the
current suggestion.
I believe the current edit rights are abusive and many supply chain attack
are carried with that.
by lowering the complexity the attack would be more common and the options
would larger for different domains.
Also some enterprises hold domain1.com and domain2.com and might wish for
domain1.com to delete domain2.com cookie this should be allowed with
relevant security features



On Fri, 1 Nov 2024 at 22:38, Steven Bingler <bingler@google.com> wrote:

> Hi All,
>
> Browsers will send any cookies that a given request has access to (i.e.:
> domain, path, secure-ness), meaning that any server that receives these
> cookies also already has write access to all those cookies.
>
> Since the purpose of this proposal is to target “cookie crust” then these
> are presumably cookies the server is receiving from the client. So, imo, it
> follows that a `Delete-Cookie: foo` request should delete any cookies that
> match the name “foo” regardless of their domain/path. Perhaps this could be
> made more precise and require both the cookie’s name and value to limit
> collateral damage?
>
> This isn’t dangerous as it doesn’t introduce new behavior, it’s just a
> convenience so the server doesn’t have to guess all applicable domain/path
> combinations (well, it could be a footgun). Any hosts worried about
> malicious sub/super-domains should consider the public suffix list as Yoav
> mentioned.
>
> But I question how useful this is and whether it’s worth the added
> complexity. 6265bis has a requirement that all UAs limit the longest
> specifiable expiry of a cookie to 400 days in the future. Chrome has had
> this behavior for a couple of years now meaning that any orphaned cookies
> with far-reaching expiry dates have since been deleted. It’s possible that
> some orphaned session cookies still exist but Chrome and other UAs have
> methods for deleting those as well.
>
> Given all that I believe it’s increasingly less likely for a server to see
> any “cookie cruft” after a ~year and so I’m leaning against the creation of
> a `Delete-Cookie` header given the complexity/usefulness tradeoff.
>
> - Steven
>
> On Thu, Oct 31, 2024 at 11:53 PM Yoav Weiss <yoav.weiss@shopify.com>
> wrote:
>
>> It seems to me that it would make sense to mirror the domain-based scope
>> of cookies here.
>> That is - if you can get these cookies in requests to your origin, you
>> can also delete them.
>>
>> So, if b.example.com have set domain-wide cookies on example.com,
>> a.example.com would be able to delete them. But it wouldn't be able to
>> delete host-specific cookies for b.example.com. Does that make sense?
>>
>>
>> On Thu, Oct 31, 2024 at 6:18 PM Rory Hewitt <rory.hewitt@gmail.com>
>> wrote:
>>
>>> Yeah, the existing clear-site functionality has a big security risk and
>>> massive blast radius.
>>>
>>> My thinking on subdomains is that if you own "customer1.saasprovider.com"
>>> (and potentially own subdomains within that, e.g. "
>>> d999.customer1.saasprovider.com") then there is certainly the
>>> possibility that, for reasons fair or foul, your landlord ("
>>> saasprovider.com") may send "Delete-Cookie: abc;subDomains=true" and as
>>> a result *your* "abc" cookie in *your* "customer1.saasprovider.com"
>>> domain is deleted, along with the "abc" cookie in the "saasprovider.com"
>>> domain and maybe other subdomains.
>>>
>>
>> Arguably, saasprovider.com should be on the PSL
>>
>>
>>>
>>> But...
>>>
>>> Presumably your landlord isn't malicious, so either this scenario would
>>> happen because they're hacked or they make a stupid mistake. These things
>>> obviously do happen, but is that reason enough to not allow otherwise
>>> useful functionality. We're talking about cookies being deleted, which is a
>>> low-ish risk, no?
>>>
>>> We could, of course limit this to certain cookies - perhaps no "Sec-*"
>>> cookies or those without the "Secure" attribute or to those which have a
>>> domain implicitly (i.e. it wasn't included when the original Set-Cookie
>>> header was sent to create it.)
>>>
>>> To me, the benefits of allowing this subdomain functionality outweigh
>>> the drawbacks. But that's just me.
>>>
>>> ‪On Thu, Oct 31, 2024 at 9:38 AM ‫רועי ברקאי‬‎ <roybarkayyosef@gmail.com>
>>> wrote:‬
>>>
>>>> A better mechanism for the clear-site-data would be
>>>> to
>>>> 1.delete only subdomains cookies that also hold that flag (allow-parent
>>>> domain-deletion=true)
>>>> 2.where the subdomain cookie has a list of domains allowed to delete
>>>> this cookie.
>>>> 3.a request should be sent to the subdomain web server to approve that
>>>> in which the approval logic would be on the subdomain server side.
>>>>
>>>> The same 3 suggested solutions are also security architectures for the
>>>> feature you suggested (Yoav, Rory).
>>>> That way you may add a parent to subdomain deletion without the risk of
>>>> supply chain attack as that behavior is implemented by the subdomain.
>>>>
>>>>
>>>>
>>>> ‪On Thu, 31 Oct 2024 at 18:18, ‫רועי ברקאי‬‎ <roybarkayyosef@gmail.com>
>>>> wrote:‬
>>>>
>>>>> Dear Patrick,
>>>>>
>>>>> You are correct that risk is also available in that sense as well.
>>>>> But two wrongs don't make a right. Do you believe this supply chain
>>>>> risk is irrelevent?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 31 Oct 2024 at 18:13, Patrick Meenan <patmeenan@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I agree in principle to subdomains-only, but wouldn't the risks
>>>>>> called-out also be a problem with clear-site-data which wipes out all
>>>>>> cookies (including parent and horizontally to peers)?
>>>>>>
>>>>>> ‪On Thu, Oct 31, 2024 at 12:02 PM ‫רועי ברקאי‬‎ <
>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>
>>>>>>> Rory please read my response.
>>>>>>>
>>>>>>> I agree with Rorry on most of the solution.
>>>>>>> I believe an issue may be rissen when an authority example.com may
>>>>>>> delete a cookie for a.example.com may have supply chain attack
>>>>>>> vector possibilities therefore im against that solution.
>>>>>>> As a tennant of a domain (owner of a subdomain) I wouldnt want my
>>>>>>> landlord ie the domain the company I buy services from to delete the
>>>>>>> cookies of my users.
>>>>>>>
>>>>>>> Take in mind that many subdomains that uses SAAS have their scripts
>>>>>>> run as well from the parent domain. therefore a supply chain/DOS attack may
>>>>>>> take place via removing access to users by deleting their cookies.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 31 Oct 2024 at 17:45, Rory Hewitt <rory.hewitt@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Since the "Delete-Cookie: abc, def" is a response header, then if
>>>>>>>> sent from a server at e.g. bob.example.com, I would expect it to
>>>>>>>> only delete the "abc" and "def" cookies in the bob.example.com
>>>>>>>> subdomain. Allowing even a higher iste (i.e. clearing the "abc" and "def"
>>>>>>>> cookies at the example.com root domain seems very dangerous. In a
>>>>>>>> federated world, we have things like "customer1.saasprovider.com"
>>>>>>>> who is completely unrelated to "customer2.saasprovider.com", and I
>>>>>>>> wouldn't want either of them to to be able to delete cookies at the "
>>>>>>>> saasprovider.com" root domain, since they could have been placed
>>>>>>>> there by either customer.
>>>>>>>>
>>>>>>>> However, allowing "Delete-Cookie: abc, def" sent from
>>>>>>>> bob.example.com to be able to delete those cookies from both
>>>>>>>> bob-example.com and all *.bob.example.com subdomains seems more
>>>>>>>> reasonable, IF one assumes that the bob.example.com server in some
>>>>>>>> way 'controls' its subdomains.
>>>>>>>>
>>>>>>>> In short, the only thing that should be able to delete cookies from
>>>>>>>> a domain is a Delete-Cookie header sent from that domain or a 'higher'
>>>>>>>> (closer to root) domain.
>>>>>>>>
>>>>>>>> Of course, the header could be enhanced in a similar way to HSTS:
>>>>>>>>
>>>>>>>> "Delete-Cookie: abc, def;subDomains. ghi"
>>>>>>>>
>>>>>>>> indicating that (if sent from bob.example.com), the following
>>>>>>>> cookies should be deleted:
>>>>>>>>
>>>>>>>> * "abc" if it has a Domain of bob.example.com domain
>>>>>>>> * "def" if it  has a Domain of bob.example.com domain or any
>>>>>>>> subdomains of bob.example.com
>>>>>>>> * "ghi" if it has a Domain of bob.example.com domain
>>>>>>>>
>>>>>>>> But that's getting into more complexity that maybe isn't necessary.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 31, 2024 at 4:55 AM Patrick Meenan <patmeenan@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I'm assuming the scope would be similar to clear-site-data:
>>>>>>>>> "cookies" where, at least in w3c land, it clears across all of the
>>>>>>>>> subdomains in the "registered domain" (
>>>>>>>>> https://www.w3.org/TR/clear-site-data/#clear-cookies), just with
>>>>>>>>> the ability to target a specific name instead of nuking everything.
>>>>>>>>>
>>>>>>>>> Should it be limited to the direct hierarchy or should it also
>>>>>>>>> impact same-level origins like clear-site-data does? i.e.
>>>>>>>>> bob.example.com clears from bob.example.com and example.com but
>>>>>>>>> should it be able to target deleting from alice.example.com?
>>>>>>>>>
>>>>>>>>> On Thu, Oct 31, 2024 at 6:57 AM Yoav Weiss <yoav.weiss@shopify.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ‪On Thu, Oct 31, 2024 at 11:49 AM ‫רועי ברקאי‬‎ <
>>>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>>>
>>>>>>>>>>> As a first party coockie holder you may set an expiration date
>>>>>>>>>>> on the coockie you have created.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sure, but since setting an expiration date requires predicting
>>>>>>>>>> the future, we need a way to correct past predictions that didn't quite
>>>>>>>>>> work out.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Allowing cross site coockie deletion would enable issues for
>>>>>>>>>>> users as an attacker may remove all mostly used coockie names
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Can you expand on that? I wouldn't expect a server to be able to
>>>>>>>>>> delete cookies that it can't receive, if that makes sense.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Oct 31, 2024, 12:39 Yoav Weiss <yoav.weiss@shopify.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Oct 31, 2024 at 11:15 AM Daniel Stenberg <
>>>>>>>>>>>> daniel@haxx.se> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 31 Oct 2024, Yoav Weiss wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> > `Delete-Cookie: name1, name2` as an example syntax, which
>>>>>>>>>>>>> seems simple
>>>>>>>>>>>>> > enough and can get the job done.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since cookies are hierchical, it should probably be noted that
>>>>>>>>>>>>> this list
>>>>>>>>>>>>> identifying 'name1' and 'name2' can in fact match numerous
>>>>>>>>>>>>> cookies (for
>>>>>>>>>>>>> different paths), not just two and there is no way for this
>>>>>>>>>>>>> syntax to delete
>>>>>>>>>>>>> just a subset of them.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> That's true. At the same time, the use case at hand is one
>>>>>>>>>>>> where we want to delete cookies when we have no knowledge of their path.
>>>>>>>>>>>> So I believe it's fine to delete all matching cookies.
>>>>>>>>>>>>
>>>>>>>>>>>> +Colin Bendell <colin.bendell@shopify.com> to keep me honest,
>>>>>>>>>>>> as he's closer to this work.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>>   / daniel.haxx.se
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rory Hewitt
>>>>>>>>
>>>>>>>> https://www.linkedin.com/in/roryhewitt
>>>>>>>>
>>>>>>>
>>>
>>> --
>>> Rory Hewitt
>>>
>>> https://www.linkedin.com/in/roryhewitt
>>>
>>