Re: Delete-Cookie header??

Personally I don't think changes to the security model of cookies are a
good idea. This should just be a different way to name cookies that you
already could have set.

On Sun, Nov 3, 2024 at 2:20 AM Patrick Meenan <patmeenan@gmail.com> wrote:

> Specifically, the request was to use the same bounds already in place for
> set-cookie. Registerable domain 1 should not have access to registerable
> domain 2.
>
> Multiple domains within a given registerable domain where set-cookie can
> already access is the discussion point.
>
> On Sun, Nov 3, 2024 at 3:12 AM רועי ברקאי <roybarkayyosef@gmail.com>
> wrote:
>
>> 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
>>>>>>>>>
>>>>>>>>

-- 
Astra mortemque praestare gradatim