Closed Bug 906448 Opened 11 years ago Closed 4 years ago

An ETag set outside of private browsing mode will be sent in private browsing mode and vice versa (also with containers)

Categories

(Firefox :: Private Browsing, defect)

26 Branch
x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1574956

People

(Reporter: tom, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: privacy)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

1. Visit this proof of concept: http://lucb1e.com/rp/cookielesscookies/
2. Type some text and click "Store" to have the server associate that text with a session ID set via ETag
3. Press Cmd+Shift+P to open a new private browsing window
4. Visit the same URL

(Also works if you enter the text in private browsing mode and visit the URL again in normal mode).


Actual results:

You see the text you entered in normal mode in the private browsing window.


Expected results:

Firefox should not have leaked an ETag acquired outside of private browsing mode when in private browsing mode (and vice versa).

I can reproduce in 23 and Nightly. Many users could be harmed by this security problem, but it's already out in the open so I won't check the box.
There is bug 231852 about that subject too.
Component: Untriaged → Networking: Cache
Depends on: 231852
Product: Firefox → Core
The problem is not in the cache but in the session store.

Extended STR:
0. Clear cache
1. Visit this proof of concept: http://lucb1e.com/rp/cookielesscookies/
2. Type some text and click "Store" to have the server associate that text with a session ID set via ETag
3. Press Cmd+Shift+P to open a new private browsing window
4. Visit the same URL
5. => you see the text
6. Refresh the page (in the PB window)
7. => you don't see the text
8. Close the PB window
9. Refresh the non-PB window page
10. => no text in the form

Extended STR2:
0. Clear cache
1. Visit this proof of concept: http://lucb1e.com/rp/cookielesscookies/
2. Type some text and click "Store" to have the server associate that text with a session ID set via ETag
3a. Restart the browser
3. Press Cmd+Shift+P to open a new private browsing window
4. Visit the same URL
5. => you DON'T see the text

I checked in Wireshark we are not sending out the stored etags.  So, this seems like a problem with session store or form fill that fills the textarea with the previously stored text.  Tracking here actually doesn't work.
Component: Networking: Cache → Session Restore
Product: Core → Firefox
Version: 23 Branch → 26 Branch
Status: UNCONFIRMED → NEW
Component: Session Restore → Private Browsing
Ever confirmed: true
Keywords: privacy
Also applies to Containers and may cause problems for First Party Isolation.
Summary: An ETag set outside of private browsing mode will be sent in private browsing mode and vice versa → An ETag set outside of private browsing mode will be sent in private browsing mode and vice versa (also with containers)
Could we remove the "Etag" word from the title?  It's pretty confusing, since ETags are HTTP cache related response/request header.  And this is about form filling and absolutely not about caching.
On Firefox 62.0b10, I can reproduce this issue across containers, even with form filling (autofill) turned off.
The PoC is slightly flawed. What you are experiencing is the way the unique identifier is created. The PoC uses your IP (and user agent I think) to generate it.

- Read the comments: https://www.ghacks.net/2017/12/09/a-solution-to-etag-tracking-in-firefox/#comments (Kane & Pants' dialog at the top)
   - Note: etag info IS cleared with cache
- Read the "Technical stuff (and bugs) specifically about this demo" on the PoC page (scroll down) - repeat (author said the test has bugs)
- Read this: https://anonymous-proxy-servers.net/blog/index.php?/archives/400-Cookieless-Cookie-Fake-Test.html - which goes into depth on the PoC
- Loads of discussion here: https://github.com/ghacksuserjs/ghacks-user.js/issues/179#issuecomment-350527923 (start about that comment and read for a while)

In order to watch exactly what is going on, just monitor your headers in real time (etag response headers and if-none-match). The PoC is still useful for that - to demonstrate that ETAGs can be used to track (as long as you don't change IP or UA). But the process is flawed, and I can't be bothered to step through it all again - its kind of a chicken & egg problem.

To defeat ETAGs (besides disabling disk and memory cache), you can modify the ETAG response header: https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.2.4-Header-Editor - do this and the PoC fails all. the. time.

-------
I have done no testing with Containers - that's up to you guys to make sure that containers as an Origin Attribute is isolated. PB mode doesn't use cache (right?), and FPI should already isolate cache (bug 1260931, also bug 1317927)
FYI: Bug 1249067 -> Bug 1264577 : tests for isolation of cache (for OA's)
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.