1967522 - Firefox 138 sending duplicate cookies after cached request

Status: RESOLVED DUPLICATE of bug 1965056

(Core :: Networking: Cookies, defect)

Description

[Christopher McDonnell]

Attachment: har_snippet.har

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:138.0) Gecko/20100101 Firefox/138.0

Steps to reproduce:

I upgraded from firefox 137.0.2 to to 138.0. I also tested this in 138.0.4, and the problem still remains. Downgrading back to firefox 137.0.2 resulted in the issue being fixed, so I am making the issue here.

I then tried to load our companies internal Kibana page. After further investigation I discovered that the browser cache and the cookie state interacted in weird ways.
Everything work fine when I disable the browser cache, but when I enable it, a cached request to a route that includes a set-cookie in the response results in a duplicate cookie being sent in the next request. (See HAR file below)

To state more formally:

1. Make a request that will return a set-cookie header, and has the ability to be cached
2. Make that request a 2nd time, such that the request is cached
3. Make a separate request on that domain, and see duplicate cookies with the same key

Actual results:

I see the sid cookie in the HAR file sent twice on the 2nd request.

Expected results:

I should not see duplicate cookie names in any request.

Comment 1

[David Lam]

I can confirm that this issue happens on my Kibana instance at the exact API endpoint and the same Firefox version:
GET /internal/data_views/fields?pattern=logs-*&meta_fields=_source&meta_fields=_id&meta_fields=_index&meta_fields=_score&meta_fields=_ignored&allow_no_index=true&apiVersion=1 HTTP/1.1

Two sid (HttpOnly) duplicated cookies with the same value are sent, which causes an authentication error and the server to kill the sid cookie with a Set-Cookie: sid=;, thus invalidating the session.

This issue happened after upgrading to Firefox 138, and I couldn't reproduce this on Edge/Chrome.

Comment 2

[David Lam]

I am using the Header Editor plugin to rewrite the Cache-Control header returned from the server, and it seems like it works to workaround the logout issue until this bug is fixed:

{
	"receiveHeader": [
		{
			"enable": true,
			"name": "Kibana Logout Workaround",
			"ruleType": "modifyReceiveHeader",
			"matchType": "prefix",
			"pattern": "https://kibana.hostname/internal/data_views/fields?pattern=",
			"exclude": "",
			"isFunction": false,
			"action": {
				"name": "cache-control",
				"value": "private, no-cache, no-store, must-revalidate"
			}
		}
	]
}

Comment 3

[Sunil Mayya]

Thanks for sharing the workaround.
This looks like duplicate of Bug 1965056.