Closed Bug 1958422 Opened 1 year ago Closed 1 year ago

cookieStore.delete() is unable to delete cookies that were set using cookieStore.set(), when invoked on a page whose URL includes a subdomain

Categories

(Core :: Networking: Cookies, defect, P2)

defect

Tracking

()

VERIFIED FIXED
139 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox137 --- disabled
firefox138 --- disabled
firefox139 --- verified

People

(Reporter: dholbert, Assigned: baku)

References

Details

(Keywords: sec-low, Whiteboard: [necko-triaged])

Attachments

(2 files)

STR:

  1. Be sure you have dom.cookieStore.enabled set to true (it's true by default only in Nightly right now, as of bug 1953368).
  2. Visit https://www.example.org/ (note: the "www" subdomain is important for triggering the bug; it doesn't repro if you instead went to example.org)
  3. Paste and execute the following in your web console:
async function logCookieVal(name, logPrefix) {
  let result = await cookieStore.get(name);
  let message = `${logPrefix}, got ${result}`;
  if (result && result.value) {
    message += ` (value = '${result.value}')`;
  }
  console.log(message);
}

logCookieVal("foo", "Expecting to be initially null");

await cookieStore.set("foo", "bar");
logCookieVal("foo", "Expecting to show value bar");

await cookieStore.delete("foo");
logCookieVal("foo", "Expecting to be null after deletion");

ACTUAL RESULTS:
This is my log output:

Expecting to be initially null, got null
Expecting to show value bar, got [object Object] (value = 'bar')
Expecting to be null after deletion, got [object Object] (value = 'bar')

EXPECTED RESULTS:
The last line there should've shown "got null" to report that the cookie was removed. i.e. the cookie should have been deleted.

Notes:

  • I initially ran into this when poking at bug 1949743 (a WebCompat Site Report for an Enphase website); I posted some diagnostic notes over there (bug 1949743 comment 19) before realizing I could repro this on www.example.org as well.
  • I'm pretty sure this isn't actually the cause of that enphase bug -- in part because I can still reproduce the user-facing issue at the Enphase site even if I disable the cookieStore about:config pref. (Hence, spinning this off as a separate bug.)
  • I'm filing this as security-sensitive since I see that we've got a similar-sounding issue described in bug 1953368 comment 6 that we're treating as security-sensitive. (This bug here is a case where a site can't delete its own cookie, which is not in-and-of-itself security-sensitive, but I think this is a version of a broader issue that has security implications.)

valentin: I'm not sure if this particular failure case is already known -- if it is, feel free to dupe as-appropriate. Thanks!

Summary: cookieStore.delete() is unable to delete cookies that were set using cookieStore.set() → cookieStore.delete() is unable to delete cookies that were set using cookieStore.set(), when invoked on a page whose URL includes a subdomain
Group: core-security → network-core-security
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]

I think the spec for .delete() is wrong or incomplete -- looks like it wasn't updated with all the properties nor defaults that match .set(). We might have some bugs of our own on top.

If I go to https://www.example.org and do

let cookie = {name:"foo", value:"bar", domain:"www.example.org", path:"/", partitioned:false};
await cookieStore.set(cookie);
await cookieStore.delete(cookie);

then the cookie gets created but not deleted.

If I change the domain to "example.org" then the above both creates and deletes the cookie. It looks like .delete() is just always using a fixed domain of the eTLD+1, in both forms and ignoring the cookie options even when explicitly set. That would be the problem from bug 1951750, but it looks like D240695 did fix delete() in the same way as set(). I don't know why only set() is behaving as if it's fixed.

See Also: → 1951750
Keywords: sec-low

We aren't passing the domain to the options in the Delete(), this is maybe expected because we don't explicitly mention the domain when calling await cookieStore.delete("thing"). Maybe we should update the options.domain with the principal's host (not base domain) somewhere around here since the validate domain function is just getting a free pass due to the empty string

Got ahead of myself, it looks like we pull the hostname out of the uri field later on

Assignee: nobody → amarchesini
Group: network-core-security → core-security-release
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 139 Branch

VERIFIED FIXED in NIghtly 139.0a1 (2025-04-15)

The STR from comment 0 now produce these EXPECTED RESULTS (notably the final line is now correct):

Expecting to be initially null, got null
Expecting to show value bar, got [object Object] (value = 'bar')
Expecting to be null after deletion, got null

Status: RESOLVED → VERIFIED
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: