Re: Delete-Cookie header??

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.

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