Re: Delete-Cookie header??

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
>