Since session restore saves and restores session cookies, it significantly modifies expectations around session cookies (namely that session cookies expire when the browser quits). This can result in session cookies being kept alive for much longer in Firefox than expected.
This has security implications as the longer a cookie is kept alive the great the risk of a brute force attack succeeding. Best practices around sliding window (i.e. idle) session cookie lifespans recommend a time-out of somewhere between 5-25 minutes. Websites that expect cookies to live longer than a day or two generally use 'persistent' cookies instead.
I'm proposing that we should implement an absolute session cookie lifespan limit of 7 days, which means that a session cookie would expire after 7 days regardless of sliding window (keepalive) behavior.
Another approach could be to implement a sliding window time limit of say 24 hours, but that would not necessarily address the underlying issue of session cookies being kept alive potentially indefinitely.
See also bug 443354, "Save and Quit" tabs should not save session cookies of to-be-restored tabs.
Yes, this grew out of discussions around bug 443354, which as written the Firefox team does not want to implement because the current behavior is useful for some people and not necessarily dangerous if you never ever share a computer.
This and bug 529899 are partial solutions, though it really seems simpler to just offer an option with the home page setting to save my tabs with/without data.
The proposed solution may be problematic: if the objection to bug 443354 is that users expect to restart their browser and have everything "just work", having sites mysteriously fail to do so every seven days may be worse than consistently forgetting session data.
> having sites mysteriously fail to do so every seven days may be worse than
> consistently forgetting session data.
Yes, I don't like that either. I sometimes keep my shopping pages open long time, and are happy when the shop doesn't expire me, so neither should Firefox.
I don't understand how this would help. What kind of "brute force" attack would this prevent? Is it an attack involving the client or the server?
Session cookie should expire after 5-25 minutes. If a site wants a session to remain alive for a week it should use a persistent cookie. Or we could stop persisting session cookies as part of tab restore. If someone can find examples of long live session cookies on major sites please put them in this bug.
> Session cookie should expire after 5-25 minutes.
Who says that? The spec says:
"Max-Age The default behavior is to discard the cookie when the user agent exits."(RFC 2109 4.3.1, RFC 2965 3.3.1)
You could loosen the spec and redefine session cookies as one that applies only to the current *visit* of the website. That ends at latest when the user closed all pages of the site.
There's absolutely nothing that support expiring the cookie after a certain time. In fact, if the site wanted that, it would have set Max-Age. It also breaks sites.
As I said, I get really annoyed with shopping sites that empty my basket or even log me out just because I gather more information about the products I am about to buy, or want to think more about it before committing to the purchase. That may take hours, sometimes days.
*** Bug 636209 has been marked as a duplicate of this bug. ***
*** Bug 650298 has been marked as a duplicate of this bug. ***
See bug 650298 for an important threat situation.
So, this bug title correctly specifies the problem, but the solution proposed here is IMHO not the proper one. Apart from interfering with normal use (see my comments above), it's not a complete fix for bug 650298. I close the browser and expect sessions to be gone, not somebody being able to go to my computer immediately after I leave the room and explicitly closed the browser.
We should just do what the spec says and empty session cookies when the browser exists. "Session restore" should not restore cookies.
*** Bug 650332 has been marked as a duplicate of this bug. ***
*** Bug 660994 has been marked as a duplicate of this bug. ***
*** Bug 657226 has been marked as a duplicate of this bug. ***
*** Bug 662306 has been marked as a duplicate of this bug. ***
*** Bug 693275 has been marked as a duplicate of this bug. ***
*** Bug 697684 has been marked as a duplicate of this bug. ***
This bug is now 2 years old, and the DUPs show that this is still a significant threat.
The bug I filed, 697684, has just been marked a duplicate of this. It's subtlely different as I was interpreting the bug as being with the preferences option "Accept 3rd party cookies. Keep until I close Firefox" -- which is not enacted. Rather than the complicated sliding scale suggested here, I'd just like there to be two options in the preferences, with the difference made clear. So that people who choose to keep their tabs but not their cookies can do so.
> two options in the preferences, with the difference made clear.
> choose to keep their tabs but not their cookies
That's a good idea to break the tie that we have here.
*** Bug 716984 has been marked as a duplicate of this bug. ***
This is a huge security issue, and the fact that Mozilla even allows such functionality makes me question what other security issues Firefox has hidden under the covers. This behavior makes it very easy for someone with malicious intent to enable "Show my windows and tabs from last time" on a public computer and then camp-out and wait for someone to close the browser thinking they had destroyed their session. Until this issue is addressed, not only will I not be using Firefox on public computers anymore, but my best practice moving forward will be to block Firefox from public facing applications that require authentication.
If a public computer allows visitors to change browser prefs, you have bigger problems than session restore.
You must look at this issue from the a web application security perspective. If I have a public facing web application that requires authentication, and I have no control over how the Firefox preferences are configured on public/shared computers, then I have no way to guarantee that my end users sessions are protected if they are using Firefox with "Show my windows and tabs from last time" enabled. From a application security perspective I have to assume that my end users won't hit Logout, and that the user may assume by closing the browser that their session was destroyed (not realizing that "Show my windows and tabs from last time" is enabled). Since I have don't have control over how Firefox is configured on public/shared computers, then my only option for securing my application against someone hijacking a previous users session on a public/shared computer is to block all users from using Firefox on our sites.
Dan, Jesse is saying that from a web app perspective, you cannot trust such a host *at all*.
If you want to continue this point, please file a new bug. This bug here is talking from a user perspective, not a web app perspective.
Until this new feature its always been the case that application end-users as well as application providers could trust that when a user agent exits that it does not leave any lingering sessions active. So I think the point is valid from both the user and application perspective.
The word "default" used in the specification leaves a lot to interpretation "Max-Age The default behavior is to discard the cookie when the user agent exits."(RFC 2109 4.3.1, RFC 2965 3.3.1), so I can see how you could make the argument that since "Show my windows and tabs from last time" is not enabled by default that Firefox does conform to the current specification.
What are your thoughts about RFC 2109 4.2.2 where the specification states:
The user agent (possibly under the user's control) may determine
what level of security it considers appropriate for "secure"
cookies. The Secure attribute should be considered security
advice from the server to the user agent, indicating that it is in
the session's interest to protect the cookie contents.
Given Firefox's strong commitment to security (http://www.mozilla.org/en-US/firefox/security/); what about an approach where session cookies marked Secure are always destroyed on exit? The specification seems to leave this decision up to the user agent...and since it says "(possibly under the user's control)" it would seem you could make this the default behavior without the option to disable it.
The spec also states that we can use a Cache-Control header to stop the user agent from caching the session cookie. Do you know if Firefox adheres to this requirement if "Show my windows and tabs from last time" is enabled?
RFC 2109 4.2.3
* To suppress caching of the Set-Cookie header: Cache-control: no-
The whole point of the feature is to act as if the browser was never closed. Why should updating (and therefore restarting) my browser require me to lose all my state?
If you want to limit session lifetimes just expire your session tokens more eagerly - the browser is an /user/ agent.
Last comment...I think I've made my point clear.
Simple, don't update your browser until you've finished what your working on. And if you lose your state then it's probably because the site intended it that way. If not, then the site should have used persistent cookies if they had state information that they had intended to be persisted. Session cookies are not to be saved past the life of the browser process because it is a security risk, it that simple.
Think like a criminal for a second. Go to a public place where they have shared computers using Firefox and change the Firefox settings so "Show my windows and tabs from last time". Now sit back at a distance and wait for someone to login to their Gmail, or bank account then close Firefox without clicking the logout button. As soon as they leave open Firefox and your in. Your below average criminal can pull this one off without an ounce of computer skills.
This is a very big security hole and it should be closed.
James, while I don't really want to add more noise to this bug, I think you're conflating two different things here: Firefox is clearly able to differentiate a restart from explicitly closing the browser, as evidenced by the behavior when "When Nightly starts:" is set to either "Show a blank page" or "Show my home page". With this setting, closing and reopening the browser will not automatically restore the previous session, but restarting the browser for an update or a change to extensions *will*.
I think everyone can see the advantages of saving session data across restarts, i.e. when you expect the browser to pop back up right away.
When you explicitly close the browser and then reopen it later on, however, this is not so obvious. For one thing, web pages associated with stored tabs may have changed, leaving the session data significantly out of date. The security problems mentioned above are another disadvantage. I'm not saying what Firefox does right now is *wrong*, per se - for instance if the browser crashes, a user will expect (or at least hope) that their data was saved. On the other hand that same user may give up in frustration, not realizing the next person to open the browser will see their data. So it's not clear that Firefox' current behavior is unequivocally *right*, either.
"The whole point of the feature is to act as if the browser was never closed....If you want to limit session lifetimes just expire your session tokens more eagerly - the browser is an /user/ agent."
You assume this, but it is not communicated to the *user* that you think this is the point of the feature. A perfectly competent, computer-literate agent may think that the point is to enable them to pick up where they left off -- but that they can additionally select the option "Accept 3rd party cookies. Keep until I close Firefox" and ensure that the cookies are got rid off. The fact that this is not actual behaviour removes agency from the user.
> A perfectly competent, computer-literate agent may think that the point is to enable
> them to pick up where they left off -- but that they can additionally select the
> option "Accept 3rd party cookies. Keep until I close Firefox" and
> ensure that the cookies are got rid off.
Exactly. I do want to keep the pages open - be it newspaper articles that I want to read or MDC tabs for APIs that I need for my work - but I chose "Keep cookies until I close Firefox" *specifically* because I don't want to be tracked forever by Google or advertisers and I want a regular cut in the tracking. I want to appear that I am a completely new user who opens these articles.
Currently, Firefox doesn't allow me that.
(In reply to Ben Bucksch (:BenB) from comment #29)
> Currently, Firefox doesn't allow me that.
This may not be obvious enough to satisfy everybody, but set browser.sessionstore.privacy_level to 2 (0 = save all session cookies, 1 = don't save https/secure, 2 = don't save any)
Firefox should do something smarter if your cookie settings and session restore settings are mutually contradictory. That needs a separate bug, though. This bug is about session restore with the default cookie settings.
I'd like to add a point to the discussion and a potential start for fixing this issue:
So far, if "Show my windows and tabs from last time" is selected, all session cookies are saved and later restored. However, most of those cookies are for pages not in the user's current tabs, but for sessions belonging to already closed ones*. If any cookie is saved and restored in a later instance of Firefox, it should at least belong to pages in the "windows and tabs from last time." Any other cookie not represented in such population should be removed if "Keep until: I close Firefox" is selected.
This keeps the current behaviour for people who, as commented, would leave their online shopping basket loaded, close Firefox and expect the basket to remain saved, while at least giving a partial solution for people worried about their cookies. If you don't want cookies for your mail to be restored you can at least close its tab, but still take advantadge of the "Show my windows and tabs from last time" option. With the current implementation, your mail info will be kept unless you explicitly log out.
* I've experienced this behaviour with Youtube's HTML5 trial (no account involved), StackExchange (no logout button) or Twitter (no login related info, since I log out). All this pages remember some of my settings between sessions, eventhough they shouldn't, and I rarely keep their tabs open between browsing sessions.
Elideb, do you have any app tabs? If so, you're probably hitting bug 704779.
Most of the bugs marked as dups of this bug are actually dups of bug 345345.
(In reply to Jesse Ruderman from comment #33)
> Elideb, do you have any app tabs? If so, you're probably hitting bug 704779.
Jesse, I did have an app tab, indeed. I've unpinned it and tested again Youtube and StackOverflow and their cookies are still restored after closing and opening Firefox. I've tested this 5 times, all of them with the same result, so I'd say the app tab was not the issue, unless they screw things permanently.
And even if that would be the case, I still think that making sure session restore only kicks in for remembered tabs (if "Keep until: I close Firefox") would be the way to go, fixing this bug and bug 704779 at the same time.
*** Bug 741768 has been marked as a duplicate of this bug. ***
I went to my banking website on a secure connection and accessed my account. I then rebooted my PC without closing the browser.
I open the FF browser and I was in the same banking web page as if I logged in again.
I should have been forced to login to my bank's website again after the reboot like I get when I close the web browser.
*** Bug 769127 has been marked as a duplicate of this bug. ***
A bug I filed, bug 769127, was marked a duplicate of this one. The interaction between Session Restore and the Privacy Settings, specifically "Clear cookies" and "Active logins" on shutdown violates the Principle of Least Surprise . There should, at the very least, be text in the preferences UI that says session cookies, and Active logins by association, will not be cleared if Session Restore is enabled.
As a user, I am not signing away my privacy rights just because multiple people have access to the machine. The browser is not being clear that my preference to clear login information has been overridden by another preference.
Additionally, I am not suggesting something as complicated as honoring session cookie duration or enforcing a 7-day maximum lifetime of said cookies. My request is either the browser delete the cookies, and obey my preference, or the browser's preferences pane tells me that Session Restore will result in the cookies not being deleted. Armed with the information, I can make an informed decision about whether Session Restore is worth the risk of secure logins persisting across sessions.
@Manoj: you can actually get Firefox to behave the way you want it to, it just isn't accessible via the UI:
"For the concerned users, they can change the hidden prefs (browser.sessionstore.privacy_level & browser.sessionstore.privacy_level_deferred) to 1 or 2 (save HTTP session cookies & no cookies respectively)."
I quite agree with you about principle of least surprise, and find it bizarre that Firefox are ignoring requests to have this as an option accessible via the UI -- and to remove the ambiguity in the current UI option.
*** Bug 807591 has been marked as a duplicate of this bug. ***
*** Bug 794253 has been marked as a duplicate of this bug. ***
The request bug 443354 is tightly connected to this one.
(In reply to Dan from comment #20)
> Until this issue is addressed,
> not only will I not be using Firefox on public computers anymore, but my
> best practice moving forward will be to block Firefox from public facing
> applications that require authentication.
(In reply to Dan from comment #22)
You look in the wrong direction. The place you need is "Clear recent history..." in the menu "Tools". Although this feature deals with other than recent stuff and with more than history. This feature needs a rephrasing into something much more general, like "Clear personal data" or "Clear navigation data".
(In reply to Dan from comment #26)
> Think like a criminal for a second. Go to a public place where they have
> shared computers using Firefox and change the Firefox settings so "Show my
> windows and tabs from last time". Now sit back at a distance and wait for
> someone to login to their Gmail, or bank account then close Firefox without
> clicking the logout button. As soon as they leave open Firefox and your in.
> Your below average criminal can pull this one off without an ounce of
> computer skills.
Anyway, if you can control the public computer, you can bug it with a key-logger. This is easy, you only need a few minutes.
(In reply to Bill Sanford from comment #37)
> I went to my banking website on a secure connection and accessed my account.
> I then rebooted my PC without closing the browser.
> I open the FF browser and I was in the same banking web page as if I logged
> in again.
> I should have been forced to login to my bank's website again after the
> reboot like I get when I close the web browser.
That is your expectation. As a user, I expect otherwise. I expect my bank to remember me, I hate having to login again and again. It is a matter of compromise between security and usability, who are always in conflict. I think it is good to let the user decide. Let's inform the user better, and let's respect the user's informed choice.
(In reply to Nicolas Barbulesco from comment #44)
> That is your expectation. As a user, I expect otherwise..... I
> think it is good to let the user decide. Let's inform the user better, and
> let's respect the user's informed choice.
I absolutely agree.
The problem is, that as is, Firefox does *not* behave in the way I think I have specified, as a user. I want to "keep my tabs" and "delete all cookies when I close firefox" -- so those are the options I select in preferences, and that is the behaviour I expect. I haven't selected an option saying "delete all my cookies when I close firefox, except for the ones for tabs that are still open", but that is what I'm getting. [Unless I make changes in about:config].
This is the point I was making in comment 17. A user who chooses these options in their preferences is already a pretty well informed user. The "bug" is in the fact that behaviour is not as the selected preferences seem to describe. Absolutely, let the user decide, but do *let* them decide. [Without needing to find this conversation online and make the changes in about:config]
Elizabeth is right. Nicolas, you are missing the point. Please try to understand the problem that people are addressing here. A key-logger is not the solution to it...
*** Bug 894858 has been marked as a duplicate of this bug. ***
*** Bug 693281 has been marked as a duplicate of this bug. ***
*** Bug 1240288 has been marked as a duplicate of this bug. ***
(In reply to Jesse Ruderman from comment #31)
> Firefox should do something smarter if your cookie settings and session
> restore settings are mutually contradictory. That needs a separate bug,
> though. This bug is about session restore with the default cookie settings.
FWIW I've filed bug 1244756 to give a warning in this case. I'm not sure giving a warning is the best solution, but just adding extra prefs or options isn't helpful unless the user already understand that these two options don't interact well.
Duplicates regarding not honoring the user preference to clear cookies on shutdown (Bug 697684, Bug 769127, Bug 794253 and Bug 1240288) have been fixed by Bug 529899 and Bug 1260360.