User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-PT; rv:1.8.1) Gecko/20061010 Firefox/2.0 If you are browsing a site that requires login through SSL and you are the owner of the account and the browser fails the restore application works restoring the session with the login, but if you are not the owner of the account there may be a problem. I detected this while i was browsing through a SSL site and Gmail and the browser failed. I then restored the session and the browser restored both sessions without asking a password. I think it should restore the sites opened but not the user sessions on the sites. Reproducible: Always Steps to Reproduce: 1. Enter a SSL site 2. Enter a non SSL site 3. Shutdown browser 4. Recover sessions Actual Results: All sessions recovered with the users accounts logged on

I believe session-cookie saving was an explicit design goal of session restore. I'm surprised we're not encrypting the data using the master password, though. I bet sites will be unhappy when they find out we're regularly writing out cookies they thought were memory-only. Make this optional? There isn't any visible way for users to turn off the session restore feature. The prefs don't even show up in about:config because there aren't any default values (that's non-standard, we strongly encourage default pref settings, to document what's relevant for the next poor schlub who has to maintain the code if nothing else).

Meant to reassign, sorry.

*** Bug 358118 has been marked as a duplicate of this bug. ***

I understand how this could be confusing for someone using a public computer or sharing a computer with a friend. People are used to "closing all browser windows logs you out" on many sites, so if Firefox crashes, they would expect to have been logged out. Does this unexpected behavior happen only for crashes, or also for things like OS shutdowns?

FYI, the bug will occur even if the OS was shut down and rebooted (while Firefox was still running and couldn't be closed by the OS). From my impression, as long as Firefox is forced to shut down for any reason, Firefox will present this problem.

Whether it shuts down or not, we're constantly writing the contents of session-only cookies into a file on disk in plain text.

I also noticed that the behaviour happens all the time. The browser seems to interpreter a not closed session as a browser crash. At least on windows...

In practice, it may be hard for Firefox to differentiate between a manual Windows shutdown and an automated one (e.g., invoked by Windows Update). Perhaps Firefox could listen for the WM_SHUTDOWN notification and present a "Save Session" confirmation dialog (which times out and defaults to No)?

*** Bug 360146 has been marked as a duplicate of this bug. ***

(In reply to comment #0) > I detected this while i was browsing through a > SSL site and Gmail and the browser failed. I then restored the session and the > browser restored both sessions without asking a password. I think it should > restore the sites opened but not the user sessions on the sites. Gmail uses persistent cookies. If you disable session restore, open Gmail, restart the browser, and open Gmail again, you'll still be logged in. However, session restore is configured by default to *not* store session cookies for SSL sites, so it's likely that the SSL site you were at was also using persistent cookies. Can you say what the secure site was, so that we can see if there's a bug here? (In reply to comment #1) > I believe session-cookie saving was an explicit design goal of session restore. > I'm surprised we're not encrypting the data using the master password, though. > I bet sites will be unhappy when they find out we're regularly writing out > cookies they thought were memory-only. By default, session restore will only restore cookies for un-encrypted sites, so we're not storing anything that isn't already in cleartext on the wire. Also, the saved data is removed from disk when the application shuts down cleanly (unless the user said otherwise), so the local exposure window for this data is only when the application is terminated without going through normal shutdown procedures: a crash or force-quit. That said, we could encrypt the file. However, I'd like to have a larger target for this than just sessionstore.js. Open up any cookies.txt file and there is a significant exposure of usernames, search terms and history data in cleartext. > Make this optional? There isn't any visible way for users to turn off the > session restore feature. The prefs don't even show up in about:config because > there aren't any default values (that's non-standard, we strongly encourage > default pref settings, to document what's relevant for the next poor schlub who > has to maintain the code if nothing else). Re: making it optional - users can set browser.sessionstore.privacy_level=2, and no private data (cookies, form data, etc) will be restored at all. Also, browser.sessionstore.enabled=false will disable the feature entirely. However, as you noted, there's no UI for these things. Re: default prefs - this bug has the patch, which unfortunately didn't make it into Fx2: https://bugzilla.mozilla.org/show_bug.cgi?id=340895 (In reply to comment #4) > I understand how this could be confusing for someone using a public computer or > sharing a computer with a friend. People are used to "closing all browser > windows logs you out" on many sites, so if Firefox crashes, they would expect > to have been logged out. The conclusion for Fx2 was that the solution was to provide a way for admins of public/kiosk deployments to turn off post-crash restoration (browser.sessionstore.resume_from_crash=false) or disable session restore entirely (browser.sessionstore.enabled=false). This is noted in the Fx2 release notes: http://www.mozilla.com/en-US/firefox/2.0/releasenotes/#issues. Maybe we should have a multi-user mode that implements conservative pref defaults for privacy and security... (In reply to comment #6) > Whether it shuts down or not, we're constantly writing the contents of > session-only cookies into a file on disk in plain text. By default, session restore saves only those cookies that are already cleartext on the wire, for non-encrypted sites, and the file only persists beyond the session in the event of abnormal shutdown. (In reply to comment #8) > In practice, it may be hard for Firefox to differentiate between a manual > Windows shutdown and an automated one (e.g., invoked by Windows Update). > Perhaps Firefox could listen for the WM_SHUTDOWN notification and present a > "Save Session" confirmation dialog (which times out and defaults to No)? > I'm not sure about the "defaults to No" part. I'd be unhappy if I had a bunch of tabs open, and then woke up in the morning and they were gone because my OS decided to reboot itself. I think that this feature is valuable to many people because of exactly the kind of scenario you describe. To sum up: If session restore is storing session cookies for SSL sites, then we have a bug in the code. However, that doesn't seem to be the specific complaint here. At issue is the question of whether we should be re/storing session cookies at all. IMHO, we're not increasing the level of exposure since the data we store is already sashaying around the internet in cleartext. Also, we mitigate the level of local filesystem exposure by removing the file at app close, except when required for restoration.

actually, my Gmail account is set up so that i have to sign in every time my browser is closed (meaning that it shouldn't have been a cookie problem) for reference, i've tested this bug three times (w/ a password-protected website like Gmail open when Firefox is closed abruptly) and it once asked me for my master password when restoring. i couldn't tell any obvious differences between my sessions, though