Re: Delete-Cookie header??

So It shall be documented that domain1 should not have access to delete
domain2 .

On Sun, Nov 3, 2024, 09:57 Yoav Weiss <yoav@yoav.ws> wrote:

>
>
> On Sat, Nov 2, 2024, 21:41 רועי ברקאי <roybarkayyosef@gmail.com> wrote:
>
>> Hey Steven
>>
>> For special SaaS you as the provider don't know the coockie name,  same
>> for wix for example.
>>
>> Secondly in regards to damain1.com on domain2.com the functionality is
>> desired by yoav ,
>>
>
> It really isn't
>
> I wish to have a security feature for that to mitigate potential risk
>>
>
>> On Sat, Nov 2, 2024, 21:05 Steven Bingler <bingler@google.com> wrote:
>>
>>> > as a parent domain may...attempt to delete any other domain cookie
>>>
>>> This is already possible and is in fact nearly trivial if a human looks
>>> at their browser's developer tools to obtain the domain and path of the
>>> cookie they want to delete. No guessing required.
>>>
>>> > 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
>>>
>>> It's not currently possible for one registrable domain to target and
>>> delete cookies of another registrable domain and I don't believe this
>>> proposal is advocating for that ability.
>>>
>>> - Steven
>>>
>>>
>>> ‪On Fri, Nov 1, 2024 at 5:46 PM ‫רועי ברקאי‬‎ <roybarkayyosef@gmail.com>
>>> wrote:‬
>>>
>>>> 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
>>>>>>>
>>>>>>