Closed Bug 1738150 Opened 2 years ago Closed 2 years ago

CORS preflight cache persists between "private mode" sessions

Categories

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

Firefox 92
defect

Tracking

()

RESOLVED FIXED
97 Branch
Tracking Status
firefox97 --- fixed

People

(Reporter: binoychitale, Assigned: manuel)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

Attached file screenshots.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36

Steps to reproduce:

We are privacy researchers evaluating the privacy implications of browser caching mechanisms. We have identified a bug in Firefox 92.0.1 that presents a privacy threat to users as it can be used to re-identify them across private browsing sessions. Specifically, we have found that cached OPTIONS requests for CORS resources persist after closing a private browsing window and opening a new one. In practice, attackers can encode a unique identifier into a series of CORS requests, and use it to track a user across private browsing sessions.

Steps to reproduce:

Open a website (in private browsing) which fetches a cross-origin resource, such that the 'Access-Control-Max-Age' header in response is set to a non-zero value.

Close and re-open the window and access the same url, and check if the OPTIONS request is still cached

In the attached screenshot, we can see that a preflight request was NOT triggered for request 31, even after closing and re-opening the private window.

Just like the example above, an user identifier can be encoded as a series of bits such that:

CORS cache HIT=1
CORS cache MISS=0

This identifier would be able to persist across private browsing sessions, which presents a potential privacy vulnerability

Actual results:

On closing the private browsing window and re-opening it, the CORS preflight cache persists and the cross-origin resource is directly fetched without a preflight request. In essence, the cache is only cleared when the browser is terminated.

Expected results:

On closing the private browsing window, the CORS preflight cache should have been erased. In other words, when the window is reopened and the website is visited, there SHOULD be a preflight request triggered for resource 31 in the above screenshot.

Summary: CORS preflight cache persists after between "private mode" sessions → CORS preflight cache persists between "private mode" sessions

The Bugbug bot thinks this bug should belong to the 'Firefox::Private Browsing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Private Browsing

Setting this to the Core-> DOM: Networking component so that the dev team could take a look over it. If this is not the right component, please move it to a more suitable one. Thanks!

Component: Private Browsing → DOM: Networking
Product: Firefox → Core

I think it's doable to clear the preflight cache on "last-pb-context-exited" but I'm not sure if this is high priority.
Christoph, what do you think?

Flags: needinfo?(ckerschb)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #3)

I think it's doable to clear the preflight cache on "last-pb-context-exited" but I'm not sure if this is high priority.
Christoph, what do you think?

Generally we should try to fix bugs where we are not clearly separating Private Browsing Mode and Regular Mode. Maybe something that Manuel could look into?

Flags: needinfo?(ckerschb)

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #4)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #3)

I think it's doable to clear the preflight cache on "last-pb-context-exited" but I'm not sure if this is high priority.
Christoph, what do you think?

Generally we should try to fix bugs where we are not clearly separating Private Browsing Mode and Regular Mode. Maybe something that Manuel could look into?

This is only for private browsing mode - the bug is that the second pb window still sees the CORS cache of the first pb window.

Manuel, do you want to take this?
What we need to do is:

  • Create a method on nsPreflightCache that removes entries from the table that have pb in their origin attributes (like this)
  • Add a static method on nsCORSListenerProxy that calls the method on nsPreflightCache
  • Maybe call nsCORSListenerProxy::ClearPrivateBrowsingCache() from here or better yet make nsCORSListenerProxy implement nsIObserver and make it observe "last-pb-context-exited".
Flags: needinfo?(mbucher)

Yes, I'd like to take this.

Assignee: nobody → mbucher
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(mbucher)
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]
Blocks: 1748664
Pushed by mbucher@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8b1d5fae296f
clear preflight cache between private mode sessions r=necko-reviewers,kershaw
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 97 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: