Closed Bug 345345 Opened 18 years ago Closed 16 years ago

Session Restore remembers logins from session cookies

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: wpt2097, Unassigned)

References

(
URL
)

Details

(Keywords: privacy, relnote, Whiteboard: see comment 14 to customize) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1

(I've only tested this with GMail so far, but it works every time.)

If FFX crashes while logged in to GMail, using Session restore will take me back to GMails main view, bypassing the login.

If I instead quit FFX normally, going back to GMail forces me to supply name and password.


This is pretty bad for public computers, where someone could easily access others personal information such in this case emails.

I hope there is a way to disable this feature for public computers, but I'm not sure it will help as admins are humans too. It will be easy to forget to turn it off and there'll be victims.


Reproducible: Always

Steps to Reproduce:
1) Start FFX and go to http://www.gmail.com/
2) Enter your details, do NOT check "Remember me.."
3) When logged in, use Task Manager to kill FFX
4) Start FFX again, use "Restore session"



Actual Results:  
Goes straight into the main list of emails, bypassing the login!

Expected Results:  
Going back to login screen, asking for name & password.
We wouldn't "accidentally" be saving session cookies so this must be by design (and generally useful -- you'd keep your shopping cart contents, for example). Were these implications considered?
Flags: blocking-firefox2?
Keywords: privacy
Yes, this is intentional and by design.

From http://wiki.mozilla.org/Session_Restore:

browser.sessionstore.resume_from_crash=false turns off automatic crash recovery, which is what I'd hope public use computers would set. I don't think this needs a visual pref, but if one were to be created, it should be squirrelled away in advancd somewhere.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Drivers felt that this wasn't worth blocking the release, but we need to be explicit in making a release note about this. Our focus is on end users and consumers, not on shared computer labs, and the value of this feature is pretty huge to that set. As dveditz notes, saving session cookies means that we can keep people's shopping carts, which is something we definitely want to do.
Flags: blocking-firefox2? → blocking-firefox2-
Keywords: relnote, uiwanted
> This is pretty bad for public computers, where someone could easily access
> others personal information such in this case emails.

This scenario is only problematic when the app crashes, and the user *leaves* the computer. Then the next user starts it up, gets prompted to restore the session, and if they do so, there's the potential for being logged in to someone else's account, if the cookie hasn't expired.

The reporter is correct: Education and documentation will not completely solve this problem.

A hard-line solution would be to have a first-run prompt asking the user whether sessions should be restored after crashes. This will force awareness of the problem. However, this is 1) super bad fugly and 2) we'd have to clearly explain the whole scenario in this prompt, or they'd probably click yes.

Another option is to have a Firefox Kiosk Edition, which is configured in a manner appropriate for public usage. A downside to this solution is that awareness of this is key, else admins will just download and install the regular version.
For kiosks you'll want to clear all private data on shutdown anyway (which of course also clears all session related data). And if you crash, you've so far risked to unwantedly expose sensitive data as well - it just wasn't that obvious. IMO the situation hasn't really become much different than with Firefox 1.5.

(In reply to comment #4)
> A hard-line solution would be to have a first-run prompt asking the user
> whether sessions should be restored after crashes.

This will of course not help the user (who isn't the first in running the browser) and maybe neither the kiosk maintainer (since it might be somebody else doing the setup) and will just plainly annoy the 99.9% other users.
yes, I'm agree with Simon. I think session restore feature should be like this : when FF will be opened after an abrupt exit, it should first ask for the master password, and if it is provided correctly , only then it will show session restore message. otherwise it may become a security problem in some cases ( for example in college computers where more than one user use same computer )
*** Bug 345830 has been marked as a duplicate of this bug. ***
(In reply to comment #1)
> We wouldn't "accidentally" be saving session cookies so this must be by design
> (and generally useful -- you'd keep your shopping cart contents, for example).
> Were these implications considered?
> 

FireFox Crash is a rare problem. Users may be little annoyed when it crashes and they have to enter there shopping cart contents again. 

> This is pretty bad for public computers, where someone could easily access
> others personal information such in this case emails.

But this will be better since most of the users(at least in India) use public computers (Cyber Cafe, Colleges) for browsing Internet.

According to the  Privacy session of the "Restore Session" design (http://wiki.mozilla.org/Session_Restore), the saved session data is cleared at shutdown.
This does not happen. 
My Gmail session was open and my computer restarted due to power shedding (It was not the browser crash). But still the session was restored after re-booting the PC.

set this preference to 'false' 
browser.sessionstore.resume_session
Actual default setting is like this :

    *  browser.sessionstore.enabled (bool) - Activate the service. Default is true
    * browser.sessionstore.resume_from_crash (bool) - Resume sessions post-crash. Default is true.
    * browser.sessionstore.resume_session (bool) - Resume sessions always. Default is false.
    * browser.sessionstore.resume_session_once (bool) - Resume session at the next application start, but not again. Default is false. 

(copied from http://wiki.mozilla.org/Session_Restore )
(In reply to comment #9)
> My Gmail session was open and my computer restarted due to power shedding (It
> was not the browser crash). But still the session was restored after re-booting
> the PC.

That's because Firefox isn't cleanly shut down during an OS restart (see bug 333907). SessionStore always kicks in if there wasn't a clean shutdown, not only on what you'd consider a crash.
*** Bug 362212 has been marked as a duplicate of this bug. ***
This is a bad 'feature' considering that I logged into a kerberos password protected resource without authenticating after rebooting a machine. It may not be such a bad issue since the workstation isn't public, but we have a number of kiosks on campus.

Moreover, what would happen if a profile is copied to your another directory and started up (assuming admin rights or public access) after a browser crash? This could pose a severe security risk to not just kiosk machines, but lab and public machines as well if data doesn't get cleared off when the machine reboots or the browser was terminated improperly.

Why not just clear the session cookies? or is there a method of filtering cookies and forcing some users to log back in to domains?
(In reply to comment #13)
> This is a bad 'feature' considering that I logged into a kerberos password
> protected resource without authenticating after rebooting a machine.

This sounds like you're using an unencrypted connection to that resource. In case you can't force people to use https, you can always globally switch off session restoring through setting browser.sessionstore.resume_from_crash to false (see bug 364972 for another privacy issue which won't be fixed before Firefox 2.0.0.2 though) or disable cookie saving by globally setting browser.sessionstore.privacy_level to 2.

BTW: as of Firefox 2.0.0.2 Session Restore shouldn't be activated after rebooting Windows machines, anyway (see bug 342885).

> Why not just clear the session cookies?

Because without _session_ cookies, half of the idea of _session_ restoring becomes moot. And home users (i.e. those without an IT department for making such changes) do actually benefit from this default behavior...
Whiteboard: [wontfix?]
Component: Security → Session Restore
QA Contact: firefox → session.restore
OS: Windows XP → All
Hardware: PC → All
Summary: Session Restore remembers logins & bypasses checks (FFX 2.0b1) → Session Restore remembers logins from session cookies
Version: unspecified → Trunk
Whilst I understand the concept of restoring things like shopping carts etc, I would also argue a case for this being the web designers responsibility. There are well designed websites out there that will restore shopping carts etc after any browser crash, but at least they require you to re-authenticate yourself. I guess a similar argument could be raised for websites should always use SSL... which also solves the security/privacy issue.

Also, my issue isn't so much the idea of restoring after a crash, it's that if you set the start up option "When Firefox starts: show my windows and tabs from last time", it has the same effect.

There has been suggestions for start up prompts for whether FF should always ask at the start if you want to save session cookies or not, or whether to ask for a master password. Neither of these suggestions is overly user-friendly, although possibly effective. But what about options like:

When Firefox starts:

 - Show my windows and tabs from last time
 - Show my windows and tabs from last time, but don't save session cookies on a clean shutdown.

You'd probably want to make it an advanced option, but this just more clearly illustrates my suggestion.

Yes, I know that if you don't save session cookies that you will most likely lose your shopping carts, or half written emails etc anyway, but at least it's up to the user to decide that. Otherwise the only other option seems to be to disable the ability to restore windows and tabs, which I don't really want to do as it's one of my favourite features of FF.

Basically, I think that restore session after a crash should be treated differently to restore tabs from last time... 

Another idea to make public users more aware could be to use the status bar to say something like "session cookies will be saved on shutdown...(click here to read more)" for the first minute the browser is started or something...  (Only if the option is to save is turned on of course)...

Anyone else have any thoughts on that? (Sorry if this is long)
Why would using the master password be user unfriendly? You have to type the master password for new logins anyway.
A master password is "unfriendly" in the case of multi-user environments, such as Internet Cafes etc. If there is a master password set by a user or administrator, every subsequent user is going to be prompted for a master password they know nothing about.

I have read somewhere that Firefox was designed around the home user, not multi-user environments, but apart from this issue, I don't know of anything else that really affects it from being used in a multi-user environment, it's a fantastic browser.
(In reply to comment #21)
> Why would using the master password be user unfriendly?

One problem is that we can't really distinguish cookies relevant for login (i.e. for which you had to enter a password first) from irrelevant tracker cookies, etc. Neither can we distinguish between text and POSTDATA you'd want to keep private at some cost from where it doesn't matter. The choice is thus to either always or never ask for the master password. I doubt that the annoyance of always asking would be worth the price.

BTW: You're supposed to have to type in one password already before accessing your (Firefox) profile: the one to your OS account. And AFAICT, as of Firefox 3.0 we don't support any OS where different accounts aren't protectable anyway.
I would say to he;l with saving my shopping cart order than to have a system restore prompt that can reveil my nuclear obomba secrets. I thinq i qan switch 2 a more sequre browzer
~qurl
Whiteboard: [wontfix?] → [wontfix?] see browser.sessionstore prefs to customize
Just create an option, similar to the don't cache encrypted pages option in IE, that say "don't restore secure connections or session logins when Firefox crashes".  I assume that we want it to still keep all the rest of our regular cookies, so only session cookies, session secure connections, and session logins should be not retained here.  This would be OFF by default.
mmortal03: there _is_ such an option, see comment 14 (privacy_level pref)
Whiteboard: [wontfix?] see browser.sessionstore prefs to customize → [wontfix?] see comment 14 to customize
As an end user whose Fox crashes regularly (some JS GC issue, never mind that now), I would absolutely hate it if my transient logins or similar data would be lost during a crash.

Comment #23 said that cookies for logins and less sensitive data aren't really distinguishable. I'll go further: because a lot of data nowadays is stored in server-side sessions and only a session cookie is sent, it's actually impossible in a number of situations to selectively erase data.
Might be worth fixing this just to stop the myriad duplicate bug reports, one of which was innocently filed by me. I agree that the usual security/convenience tradeoff is present here in its purest form, and that no user wants to hear about it much less think about it. Tricky.

Perhaps the facility to restore crashed sessions should be offered only as a plugin, like Adblock and similar, that individual users would have to seek out and install themselves, after reading a description. At least Mozilla would not be responsible for "fixing" it.
Alternatively- Session restore only available if a master password has been set, and master password must be entered to restore. The user would typically only learn of this the first time he experiences a session crash, at which point the issue could be explained in some detail. 

The default would be secure, for public computers. There would be minimal intrusion on the user's experience until there was a crash, at which point he has already been inconvenienced (probably by the power company, not Mozilla) and news of a feature he didn't know about not being available this time, but configurable for future events, might actually be welcome.
ATTENTION! Do not confuse this bug with Restore Session on unsecure sites. I am talking here about secure sites, that, uder the WORSE case scenario, should prompt the user a logon screen. Some sites, suchas several banking sites, and email acocunts such as Yahoo, do not allow saving a password in Firefox, so I NEVER LOG ON with Password Remember.

HOWEVER, this bug bypasses the security, logging the user straight in, if the previous session was shut down without LOGGING OFF, and, later, the last session was restored. It's as if Firefox does the Log In on encrypted sites I can do only manually and for which I DO NOT HAVE A SAVED password.



cr
We've now shipped Firefox with this behavior for two major releases. That's the behavior will stick with (cf. comment #2). -> WONTFIX

Feel free to file UI enhancement bugs to make clearer what will happen after a restart or to add an unobtrusive option to achieve this behavior (although we've already got one, cf. comment #14).

You might instead want to file a bug about making sure that automatically clearing cookies at shutdown clears them from sessionstore.js as well (then we'd even have obvious UI to achieve what you're asking for).
Status: NEW → RESOLVED
Closed: 16 years ago
Keywords: uiwanted
Resolution: --- → WONTFIX
Whiteboard: [wontfix?] see comment 14 to customize → see comment 14 to customize
See also bug 443354 for a proposal for a different compromise: not saving session cookies when using "Safe and Quit" in Firefox 3.
Test page: http://iwrconsultancy.co.uk/sessionvuln -find out if your browser is vulnerable. 

Quoting one authority out of many on session cookies: 

"When you create a session cookie it will continue to exist for as long as the browser remains open and will be deleted as soon as the browser is closed. This is because session cookies are actually retained in memory by the browser and are never actually stored anywhere.

At the very least the manual pages on session cookies need to be corrected, right across all of the programming websites. They are no longer accurate, in fact they are dangerously misleading when they say that session cookies are deleted at browser termination."

IF THIS WAS KNOWN ABOUT IN 2006 WHY, *EIGHT YEARS LATER* HAVE THE HTML, PHP AND JAVASCRIPT OFFICIAL MANUALS *STILL* NOT BEEN CORRECTED TO INDICATE THAT THERE IS NO LONGER ANY SUCH THING AS A SESSION COOKIE, BUT THAT ALL COOKIES ARE NOW PERSISTENT REGARDLESS OF THE CODE USED TO GENERATE THEM? THERE ARE STILL NUMEROUS OFFICIAL MANPAGES OUT THERE WHICH STATE THAT SESSION COOKIES EXPIRE WHEN THE BROWSER CLOSES. THIS INFORMATION IS NOW WRONG, AND NOT JUST WRONG, BUT *DANGEROUSLY* WRONG.

Excuse the caps, but I think someone needs a resounding stick wake-up call on this one.
So, Ian, what you request is a change to https://developer.mozilla.org/en-US/docs/Web/API/document.cookie, is that it? If so, please go ahead and add a warning to the "Writing a cookie" section.
Flags: needinfo?(mozilla)
-and, ten thousand other programming language and software product manual pages which all now incorrectly state that session cookies are not persistent? Nope, I think the onus here is on the coders to comply with the standards. Didn't I read somewhere about Mozilla being diligent about standards compliance? 

If the tail is wagging the dog, the sensible thing is to fix the tail, not nail the dog down.
Flags: needinfo?(mozilla)
BTW, I'm wondering if there is any way this permanent session-cookie situation can be detected programmatically by php or js, such that the login can be refused, or made non-cookie-based? 

AFAICS nothing about the session cookie itself hints about its 'undead' condition. Could the browser's cookie-retention settings be read by js? Probably not allowed for security reasons, I guess, but someone might know of a way to detect the situation.
Flags: needinfo?(nobody)
Frankly, I doubt that we are going to deactivate one of the most beloved features of Firefox because some (even if it's a lot of) documentation is broken somewhere on the web. I'm not sure this is Firefox-only, either.

And to answer your question, no, there is no way to get this information, either from JS or from the server.
Flags: needinfo?(nobody)
Thx for reply David, I didn't imagine that there was any js that could detect it.

I think I should also apologise for using caps, however it is exasperating (and embarrassing) when after doing your level best to make a site secure, it is pointed out that on some computers it is possible to access the site from bootup without logging on.

I can see why you might want to provide this feature for the convenience of forum users and the like. The issue is that it makes it risky to perform any priveleged actions on a computer assigned to a junior employee. Office staff are in the habit of doing exactly that -Can I borrow your computer for a moment?- and would not expect their website logon to survive a browser shutdown, and thus allow the junior employee to deface the company website, or whatever. That's why it is rather dangerous. Especially, as there would be no visible sign that the risk exists, except by manually checking the browser settings. 

The answer would seem to lie in coding a keepalive function which maintains a regular 'heartbeat' of ajax calls, and which destroys the session as soon as it sees a request which follows a period of inactivity. I'm testing something along those lines just now. 

BTW I have always been a big fan of Mozilla products, having used them since Netscape Navigator days. I have converted numerous offices from IE to Firefox, and all have thanked me for eliminating a major source of malware, and providing a generally better, more reliable, browsing experience.
I guess Private Window would be a better match for the scenario you are describing. It might be worth investigating a Guest Mode, too.
Can a Private Window or Guest Mode be activated programmatically, for example by a js window.open command? Bear in mind I don't have any direct control over the client computers.

Done a lot of head-scratching over this issue over the past few days. Thought I'd found two reasonably elegant solutions, but both proved unworkable. So, I'm left with one rather messy solution. 

1# Regularly setting a timestamp as a js global variable and then checking the time expired from the last heartbeat works very nicely to disallow session continuation if the computer has been in standby, even for a few seconds, and does so without false alarms. Unfortunately it doesn't work for saved tabs because they reload the page from the server, resetting the js variable. Pity, as that would have been a very neat solution with zero network overhead. 

2# It seems that Firefox doesn't restore POST variables on tab restore, so a method that does work is to fabricate a POST variable in all URLs using php, eg $_POST['genuinesession'] If that variable isn't set you know it's a resurrected session and you kick the user off. Unfortunately, while this works in FF it doesn't work in Chrome. I guess it's not too clever to rely on undocumented features like this anyway, since they could change between versions.

3# So far, the only method that can be guaranteed to work in all browsers is to fire pings at the server using ajax, at a rate of one every few seconds*. If the pings stop, the server destroys the session. That approach is very secure, but involves a lot of added network traffic. It also means that any brief network interruption will log the user out, which could be a major annoyance. 

*The pings really need to be this fast, because in a 'borrowed computer' scenario the lockout must happen fast enough to prevent the computer owner from restarting the browser as soon as the 'borrower' leaves the room. About 5s would be a sensible lockout target since FF will easily start in that time on a powerful computer, which thus means pinging say every 3s to allow for timing skew. A lot of traffic. 

Any thoughts on this welcome.
I've been doing web development and Firefox user for years with no idea on this issue.
I updated the MDN as been suggested in this issue but I think this issue requires user
awareness more than developer awareness.

Whats even better is that chrome is following Firefox on this -
https://code.google.com/p/chromium/issues/detail?id=128513

Any way I'm not sure this is my favorite Firefox feature any more
User awareness is obviously desirable, but two issues arise: 

No-one would expect it to be like this, and the benign-sounding 'Return to the page I last visited' gives no hint of the security issue.

Even if the user IS aware, it takes only a moment's absentmindedness in failing to log out of the website, to potentially have your online a/c hijacked by a malicious observer of that omission. Therefore in a real office environment of constant distractions, very hard to avoid even if you know of it.
I suspect you can detect this from JavaScript using this code (where sessionid is a unique id of yours related to your session):

<body>
<script>
if (sessionStorage.getItem('seshid') == sessionid && window.name != sessionid) {
  alert('page has been restored after reset');
}
sessionStorage.setItem('seshid', sessionid);
window.name = sessionid;
</script>

This works if session storage and session cookies are restored but window.name is not restored (I am guessing this, but it is likely).

Beware that: (1) window.name is *insecure* so use a random identifier and don't use a secret, and (2) the way window.name works is an unwritten rule (so ugly to depend on, also needs extra testing).
About the proposed first-start GUI questions, I think they are too detailed and a lot of users won't take the time to learn what effects will result from it with two levels of indirection. I think a much simpler first-time question like "Is this $OS_NAME account \"$USER\" for use in a public location, or by multiple users? [Why is this important?] [Public or multi-user] [private, just for me]"
(sorry for partial submit.) ... would allow to set favorable defaults for all other questions I've read in this thread.
PS: Until a decision is made, assume public mode and ask again after some time.
You need to log in before you can comment on or make changes to this bug.