Closed Bug 65947 Opened 24 years ago Closed 23 years ago

form password is remembered when hitting back button

Categories

(Core :: DOM: Navigation, defect, P3)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: bugzilla, Assigned: radha)

References

(
URL
)

Details

(Whiteboard: fix in hand)

Attachments

(1 file)

patch, never remember passwords in session history
692 bytes, patch
Details | Diff | Splinter Review 
if you go to:
http://gemal4.sprawl.dk/
the page outputs:
Cache-control: no-cache
Pragma: no-cache

but if you enter some text in the login and password and tries to login you get
an error. But when you press Back the password and login is still there.

Expected:
In other browsers when you press back to a page that has nocache the page is
reloaded.
the summary is incorrect, not sure what it's supposed to read though, i'll leave
it up to you.
Maybe the summary is better now, but marking invalid. And it isn't cache
related, it's form related.

When pressing back, Mozilla fills the form with the previously entered value,
which is a very Good Thing! If you fill out a form, submit it, but made a
mistake and go back, you wouldn't want to fill in everything again.

If you want to get rid of these values, either add a "reset" button to that
web page and press it, or reload the page. If pressing the reload button
doesn't work, click in the location bar and press the Enter key.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Summary: mozilla does respect no caching headers → Mozilla doesn't respect any cacheing headers
This is really bad bad...
What about when people leave the machine, and you can just go to the machine, 
press back a couple of times and log into a application because the 
username/password is there. That's why login pages always should use nocache.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
You should never ever leave your machine unlocked. :)
Okay, reassigning to Form Submission then, and changing summary again.

I really don't think this is a cache issue. The password is not part of the
web page (the HTML file), and that's all that is cached.

And what about the password manager? It also remembers passwords, and here
it is much more important not to leave without locking the desktop.
(Unless you use encryption for storing the passwords and let the local password
expire every few minutes.)
Assignee: neeti → rods
Status: REOPENED → NEW
Component: Networking: Cache → Form Submission
QA Contact: gordon → vladimire
Summary: Mozilla doesn't respect any cacheing headers → form password is remembered when hitting back button
in my opinion this is a network cache problem. Since the login page is nocache, 
pressing back to the login page on other pages should instruct mozilla to reget 
the login page since it's not in the cache, because of the nocache.

eric, I'll let you take a look at this.
Assignee: rods → pollmann
Setting milestone to mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
Radha, it sounds like maybe here session history should get notified when Netlib
recieves No-Cache headers so that it doesn't saves form control state for that
page?  Does that sounds right?
Eric, That does sound right. we can probably use the loadtypes for that purpose. 
nsDSURIContentListener::DoContent() can look in to the nsiRequest or the channel 
to figure that it was a no-cache request and set a loadtype(BYPASS_CACHE or 
something)  that will add the page to history but not save the form values. we 
need to check for that flag in nsDOcSHell::PersistLayoutHistoryState()

Another way is to save the values in History, but not restore it. LoaadType can 
be set to one of the existing types. See nsDocShell:Embed() and avoid restoring 
it.

cc'ing gordon. Today in a meeting with him, there was a mention of caching data 
though the page says "No-Cache". Darin, Gordo, Can you clarify  what happens in 
this situation.
Currently, if the server response says "no-cache" then we don't put it in the
cache.  In the future, this may change for POST transactions.

Also, I don't believe that nsIHTTPChannel::BYPASS_CACHE is honored.  It is just
cruft that should be removed from nsIHTTPChannel.  If this is the behavior that
you want then you can use nsIChannel::FORCE_RELOAD in the load attributes.
Assignee: pollmann → radha
These changes are a bit out of my area of expertise.  Handing to the SH guru.  :)
Status: NEW → ASSIGNED
Priority: -- → P3
Cc mstoltz.

See also bug 60877 (r. invalid), "sign-out from hotmail and then clicking on 
back button lands up inside the user's mail account".

I don't like the idea of storing POST forms, but not normal pages, when the no-
cache header is present.  That's the opposite of what we do now for pages 
without no-cache, and it just seems weird.
our current plan is to store POST responses in the cache in such a way that they
are only retreivable via session history.  no-cache pages will be stored in the
cache as well, but with an expiration time = now.  session history tells HTTP
not to validate content, which means that going back to a page with no-cache
content, will result in content being fetched from the cache.
That seems right to me.
This bug is contrary to arguments made in bug 56346. I guess this should be 
marked "won't fix"?
I tried to go to the page above and get a forbidden message. Any otehr good test 
case with no-cache controls?
I see that nav 4.7 and IE don't restore the form values when going back to 
the above page. But, based on Darin's comments above on the cache policy and SH 
usage of it, I'm marking this bug Won't fix. It is a cache-policy issue rather 
than a problem with back/forward buttons or a bug in SH.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → WONTFIX
I'm not sure if I understand this correct. But:

This is really really bad for use of Mozilla on public PC's. We have:
Cache-control: no-cache
Pragma: no-cache
on the login page of our webmail application so that people cant just press 
"Back" and login as other people.

What's the solution for us? Disable use of Mozilla?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
We discussed this last week in a meeting. This is primarily a end-user feature
issue  than a bug in cache or form value restoration. In public PC situations,
different profile can be used by each user, thus when a user exits, all the data
for that profile is deleted which includes SH and form values. Another argument
to the same problem is, what if the user submitted a wrong url and passwrod and
wanted to go back and correct it. An option of using Pref is also being
considered. Marketing is trying to help arrive at a solution for this.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla1.0
I don't understand how preferences should help.
I think of using webmail in i-cafes or on fairs or conferences.
So people reading mail somewhere always have to switch browser settings?
I think this is not useable because normal PC _users_ don't think about
this security problem.
if you are concerned about privacy in such cases, just close the browser window.
that will close the most obvious security "holes."
many (most) public machine doesn't allow you to close the browser window.
Still think this is really really bad for mozilla security...
I tend to agree with Henrik about this. The argument in bug 56346 doesn't
mention passwords. It seems reasonable that history entries should be cached,
but password fields should be an exception. THe contents of a password field
should not be remembered in history. Let's do what NS4 and IE5 do and not
remember password data. Let's not deliberately make Mozilla less secure than NS4.
FWIW, this patch makes us behave like IE and forget passwords.  This is
different than Nav 4.x's behavior.  Nav 4.x does indeed remember passwords.  Not
that I think this is a good idea, just noticed...  :)

So... since the problem and fix are layout, I'd be willing to take this bug if
you think this is a good solution, Radha.  Nominating for 0.9.2 as it improves
security...
Severity: normal → major
Component: Form Submission → History: Session
Keywords: mozilla0.9.2
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: fix in hand
Wouldn't it be possible to just remember password as long as the page you go 
back is not using "Cache-control: no-cache" or "Pragma: no-cache". That would 
solve my problems.
Remembering passwords is not related to cache controls. I don't think there is a
way thro' nsICachingChannel or any other interface to check that. Eric, I'm OK
if you want to take over this bug and fix it. But, I'm still not convinced that
this is a issue in public machines. I don't think the current behavior makes N6
less secure either. Now that dynamic profile switching is available, SH and
related form values are destroyed when the profile is changed. Sites that have
good security measures will not allow you to go back into the site, once you log
off. For example, go to netcenter, login, do your work, sign off and click back,
you are redirected to the login page.  From a embedding point of view (like in
kiosk modes), we don't believe this is an issue. 
WHat if the user forgets to sign off?
That is user's mistake. if you go somewhere else from your webmail without 
signing  off and click back, you will go back into the webmail session. we 
can't add features to cover user's stupidity. Some bank sites have a timer based 
logoff. My bank's website will automatically sign me off, if I don't perform any 
action for 1.5 minutes. 
Ok, really, really good sites use session-ids even for login-screens.
But I've not seen a single site that does so yet.
Radha, I tried (with latest nightly-build) reading my mails using the
webmail-interface of netcenter, signed out, chose the login-page from
session-history, clicked on sign in (without needing to retype my password) and
was logged in again.
I really can't afford to tell any user to use N6 or mozilla as long as this
security risk exists!
I really encourage Eric to take over this bug and to fix it, please!

P.S.: I'm not talking about users who forget to sign off, I talk about people,
seeing a browser, using webmail, signing off, feeling secure. No one really
wants to think about what to do with browser A and/or browser B to make him
forget session history!
Oops, well...  Sorry for the short notice, but I am on vacation now through
8-July-2001.

I won't be able to make sure this gets in anytime soon.  Radha, I'll leave it to
you to see if the patch does something reasonable (never save passwords in
session history), and if so, please feel free to get r/sr and check it in.
This issue appears to be related to Gagan's "clarity" bug, namely bug 90288 .
That bug is pdt+ -- if you think the two issues are related, let's try and land
Pollmann's patch too. If they are dupes of one another, then so be it --
someone should conclude this and mark it so. But note that bug 90288 makes
*strict* mention of only the pragma directive not being respected. This bug
suggests a bit more, and from what I understand from Pollmann's patch, fixes
stuff with passwords. The real problem is respecting HTTP-EQUIV directives that
tell us not to cache pages, not uniquely passwords related stuff. Cc'ing Gagan.
I am not completely convinced that forgetting passwords in SH is a good thing.
But then I'd leave that as a debate to be discussed separately. Just to clarify
bug 90288 deals with not caching (even for SH purposes) a "pragma: no-cache"
page. This means hitting back button on a page that has that will indeed be
refetched. Would let eric say if we try and refill form elements on a refetched
page. So my changes in bug 90288 may or may not affect this one directly.
PSM security comments.
About gagan's previous comment:
My opinion is that if we refetch the page (especially as a result of a pragma no
cache) then we should not use any remembered form values.


About Alexander Helm's comment:
If indeed it is still the case that one can log on to web mail, read it, log out
then be able to log back in in the way Alexander described, then that's terribly
bad.

Gagan says "r=gagan@netscape.com" and Vidur says "sr=vidur@netscape.com". 
Checking in to the trunk and marking bug FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
This is a bit late, but I'd like to point out that this is possibly too
aggressive. Occasionally I'll do something like misspell my username in
bugzilla, and go back to change it.

We already have an attribute which can be added to forms to disable the password
manager, and ie honors that as well. It makes much more sense to act on that,
instead. If its in the password manager, session history not caching it won't
make a difference.

(The attribute is autocomplete=off, see bug 63961)
I'll note for the record that the page in the url bar here has autocomplete=off
on the appropriate form.
Basing what we do on that attribute makes more sense to me, although very quick
test with ie seems to indicate that it does what we now do, and never caches the
password in session history.
This doesn't appear to be completely fixed in one edge case - see bug 92532.
verifying fixed on build 2001-08-06-04-trunk. Its not remembering the password
any more on the page in the URL.
Status: RESOLVED → VERIFIED
Bradley: if you think this is the wrong way to solving the problem please open a 
new bug. Otherwise you comments from 2001-07-19 17:38 will be forgotten.
Several new bugs have been opened - see bug 93972 and bug 93027 (which has been
fixed on the trunk)
Component: History: Session → Document Navigation
QA Contact: vladimire → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: