1562279 - Sometimes logging/signing data from Non-Private Window is preserved in new Private Window

Status: VERIFIED INVALID

(Firefox :: Private Browsing, defect)

Description

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: screencast.mp4

STR:

1. Log in into mozillaZine Forums ( http://forums.mozillazine.org/ )
2. Open "Firefox Builds" subforum ( http://forums.mozillazine.org/viewforum.php?f=23 )
3. Open "The first official 20190628 builds are not yet out" topic in new Private Window using mouse menu and "Open Link in New Private Window" item ( http://forums.mozillazine.org/viewtopic.php?f=23&t=3051377 )

FYI - on screencast 1st Firefox window is old normal session, same it's with 2nd window, only 3rd new window is in Private Mode.

Comment 1

[:Gijs (he/him)]

I assume this is a function of the sid parameter in the link. If you copy over the link (copy link location) and open it in a clean profile in a different browser (chrome, different nightly profile running) does the same thing happen?

Comment 2

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: no bug with ungoogled-chromium.png

No, it doesn't happen when I paste it in ungoogled-chromium, but oddly it happens reproducible when I paste it in Private Window in Firefox.
Also nice find, I missed that "sid" parameter in link.

Comment 3

[:Gijs (he/him)]

I can't reproduce with the STR from comment 0. The links I see on index.php don't have the sid parameter appended, but in your screencast you can see the sid was already there when observing the link hover status "bar" in the bottom right.

When I try to reproduce, from logging in, the first load of index.php itself has the sid appended (as visible in the URL bar) - this isn't the case in your screencast. If I copy-paste that &sid=... bit and append it to the URL to a specific topic, then create a separate webpage that contains the link (I guess it would work to modify the link in the extant webpage with the inspector but haven't tried) but include the &sid= bit with the link, and open that in private browsing, I can reproduce.

From reading e.g. https://www.phpbb.com/community/viewtopic.php?t=2092992 these things get appended when the website determines that cookies are busted.

I haven't tested extensively, but I could believe that what's happening is something like this:

1. phpbb uses cookies to track login state. If it determines (perhaps incorrectly, perhaps because of tracking protection, perhaps for some other reason) that cookies don't work, it uses the sid URL parameter. Both cookies and sid basically just contain a session identifier
2. the session identifier is stored in a database on the server that tracks login state
3. the database also stores the user agent
4. the php side of phpbb checks the sid with the user agent, and if they match, assumes that the user information is valid (cf. https://www.phpbb.com/community/viewtopic.php?p=4762245#p4762245 where someone is changing the source to specifically disable the user agent check when validating the sid)

This would explain why PB in Firefox works but the same link in Chrome doesn't. If you go through the same steps I described above (ie copying the sid into a link, from an sid you created in Chrome by logging in in "normal" mode, and then opening that link in a new window) in Chrome, the same steps produce a logged in session in Chrome's "Incognito" window, too.

So I think this isn't a private browsing bug, and we can unhide the bug and mark it invalid - it's something the site does, and Firefox can't really stop this. It could try to remove session identifiers from the URL, but that would require knowing which URL param is a session identifier. It'd be fairly easy to hide the sid in some way (e.g. by transforming the hash into a string consisting only of english dictionary words, and putting it in the 'q' GET variable which most search pages on the web use for the search query). So I don't think that type of thing is feasible.

Virtual, does that sound right, or is there something I'm missing?

Comment 4

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: screencast with ungoogled-chromium.mp4

Everything you wrote is correct. Thank you very much for very detailed explanation. I tried to reproduce it in Mozilla Firefox (portable stable version) and in new profile with ungoogled-chromium and it's reproducible for me too.