Re: Delete-Cookie header??

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