- From: רועי ברקאי <roybarkayyosef@gmail.com>
- Date: Thu, 31 Oct 2024 18:18:28 +0200
- To: Patrick Meenan <patmeenan@gmail.com>
- Cc: Rory Hewitt <rory.hewitt@gmail.com>, Yoav Weiss <yoav.weiss@shopify.com>, Daniel Stenberg <daniel@haxx.se>, Colin Bendell <colin.bendell@shopify.com>, HTTP Working Group <ietf-http-wg@w3.org>, Anne van Kesteren <annevk@apple.com>
- Message-ID: <CAKGRsAqtT1Q2XUNQnoFZLEfdnpGjKLof7_5zfTx=3ek5n9UzUQ@mail.gmail.com>
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 >>> >>
Received on Thursday, 31 October 2024 16:18:45 UTC