Closed Bug 155030 Opened 22 years ago Closed 3 years ago

Moz should not allow reposting password forms

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: nicklas, Unassigned, NeedInfo)

References

Details

(Keywords: helpwanted, sec-low, testcase, Whiteboard: [sg:low local]) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
BuildID:    2002063000

I think it's a security risk to be able to repost a password form using values
stored in cache. That way an unauthorized user could press Back, Repost and then
use the other users account.

Reproducible: Always
Steps to Reproduce:
1. Log in to a (php) site (with sessions) with the <input>-types text and password
2. Log out from the site
3. Press back and then Repost
I confirmed that Mozilla does resubmit the password using Bugzilla's login form.

This even works at http://www.bankofamerica.com/, which has disabled password
manager using autocomplete=off.  Autocomplete=off also makes the back button not
restore the username and password fields, which I think is intentional.  I'm
surprised that banks haven't noticed this bug.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Bad idea to repost password fields → Moz should not allow reposting password forms
Priority: -- → P2
Group: security?
Nominating...
Keywords: mozilla1.0.1
Whiteboard: [ADT1 RTM]
Target Milestone: --- → mozilla1.0.1
Adding nsbeta1+
Keywords: nsbeta1+
Any idea on what it takes to fix this one?
adding Kevin and Alex to the bug to help out jkeiser.
looks like many banks are more clever than the Bank of America. They use session
cookies and so on and do not rely on the browser alone to protect the passwords.
at  least my credit union does a good job in spite of this bug.
Any status or ETA for a fix with this?
hopefully, tommorow i can tell. i need to collect information first. on it.
i don't get the "Confirm" dialog anymore with recent builds when i try to go back.
tested with builds made today 07-02-2002
tested with bugzilla: after i posted the previous comment, i hit back and in the
past usually the "Confirm" dialog ("the page you are trying to view contains
POSTDATA ...") was displayed immediatelly. With today's build, not anymore. Try
this with the most recent build. First after you go back and try to refresh, the
"Confirm" dialog will appear, this makes ne think that we have a pretty major
problem. As long as this problem persists, this bug 155030 is invalid. i will
try to see when the regression happened and localize the change that caused it.
i will also open a new bug and make this one depend on the new bug.
maybe is not a bug at all that we show that dialog first when the user tries to
refresh.
oops: no matter how things turn out to be, this bug is still valid
Why is this marked security confidential? Is this exploitable by malicious
websites? 
is more likely a problem if someone uses a page where he logged in, then that
someone is logging out and then is leaving his PC unattended, someone else could
go back in the history and log in without problems.
That sounds like a bug in the user. It doesn't sound any more of a security
exploit than a user who lets a bad guy stand over his shoulder and watch him
type in his password. I can't see any good reason to keep this bug closed,
especially as you try to solicit help in fixing it. 
yeah, well i can't do anything about it. i'm only on the CC list and was added
today. to be honnest, i have a problem everytime i hit one of this bugs. i kinda
own all new form submission bugs, but as soon as i'm removed from the bug and
the bug is marked security-sensitive, i cannot access it anymore.
OK, i found out what is the problem with the "Confirm" dialog (see comment #10).

Here is the explanation:

The "Confirm" dialog appears only in the case that the amouts of storage space
for cached content (memory and disk together) is not big enough to keep the page
that is received as a result of a POST action(method). So, no matter which cache
option is chosen, the only thing that matters are the settings for memory and
disk cache space. Now i think that the average user will not even know what the
hell means to setup the amounts of storage space for caching. Maybe the
importance of this bug should be revised by ADT.

NICKLAS BJORK:

have you turned the amounts of storage space for caching (memory and disk) to 0?
Do you run without cache? (see previous comment for exaplanation)
lowering impact to adt2.
Whiteboard: [ADT1 RTM] → [ADT2 RTM]
The size of the cache does not matter.  I can make Mozilla repost the password
using Ctrl+R even if the page is still cached for session history.
Blocks: 143047
Is there any way to take advantage of this problem without having physical
access to the machine? Could this be the basis for a plausible remote exploit?
If so, then this is serious, otherwise not so serious. Jesse, any thoughts?
of course, if you hit CTRL+R you will re-request the page. we just lowered the
impact to ADT2, that was the reason for the arguments in comment 17. the bug is
still on the major radars.
There are only two possibilities I can see here:

(a) [FIX] *never* allow reposting of POST data when there is an input
type=password among the data

(b) [EVANG] tell the server manufacturers they need to send the Cache-Control:
no-store or Cache-Control: no-cache headers, which seems like a better
solution--having server owners deal with this keeps things flexible for other
web developers who might want to allow back and forward to work on such pages.

Does IE not have this problem?  I bet it does.
IE has the same problem (with Ctrl+R) you get the same result.
Alexandru: Does IE have the same problem if AUTOCOMPLETE="OFF" is specified on
the form?
Exploiting this bug requires having physical access to the machine.

Does Cache-Control prevent reposting?  Even if it does, I'm not sure that
webmail providers can use it (does it allow form data like typed e-mails to be
kept session history?), and many will choose not to use it because it makes
their site slower.

IMO, it's reasonable for a user to assume that clicking "log out" is sufficient
even in an Internet cafe.  I think we should treat this as a bug rather than an
evangelism issue.  It's not serious, but fixing it would make Mozilla a better
choice for Internet cafes and might make banks like us more.
I just logged into Fidelity, BofA and Yahoo mail.
When I use the Back button to go back to login none of these sites have my
password filled in and so I can't resubmit to login.

With BofA if I sign out then use my back button, my password isn't there either,
to resubmit.

On Fidelity if I sign out then use my back button, it refreshes the signin page,
with no fields filled in.

But maybe I don't get how to make this bug happen...I agree users should have
the burden to logout but if you can post a form with their data when they
*didn't* ask for mozilla to save the data, that's not good.
There is a very real problem here, though the server can (and should) fix it. 
The problem is not just the repost; the problem is that the password data is
stored in memory, in plaintext, for these cached pages.  Thus an application
could conceivably go to the cached postdata, even if the data was not
saved/restored, and find the plaintext password.

Server Fix:
Cache-Control header can be sent on just a single page (and no others)--so it
can be sent on the affected login page.  Webmail applications and other login
sensitive applications in general should be doing this anyway--they should not
depend on behavior on the client.  And since the problem happens in IE as well,
the servers *need* to fix this.

Client Fix:
Trigger on input type=password or autocomplete="off" and do not cache the page
at all in that case (or perhaps just do not cache the URL or network data.  It
makes sense from a certain paranoid POV to do this--but servers should still be
fixed if they want to deal with security problems.  Not caching these pages is
counter-intuitive and adds yet another anomaly to our already undocumented
caching behavior.

CONSEQUENCES:
You *will not* be able to go back to *any* page that was submitted with
autocomplete="off" or input type="password" once it has been purged from the
cache (and I am assuming we can cache the page but not the network data, which
might not be possible).  You will never see the page again.
Status: NEW → ASSIGNED
I agree with JKeiser. A server side solution is a more appropriate one.  The
client side solution proposed above will only add more confusion and create a
slew of session history bugs. I thought that when a password field is
encountered, we just did not store its value in forms manager as well as in
layout (nsILayoutHistoryState) irrespective of whether the page had no-cache or
no-store headers.  Was that a wrong assumption I made? or Did that behavior
regress lately. 
My $.2:

Server Fix:
Agree, banks, retailers, etc. are also responsible for their customers security.
Relying on browsers capabilities only, should not be considered enough. Many web
developers are aware of that and that is why this exploit does not work in most
of the cases.

Client Fix:
We could warn the user that the result page of a post is not cached. However, I
think that creating a fix that introduces such a special cache behaviour is not
really a top importance issue. Rahter the web developers should be evangelized.
Even if we create a fix like the one described by John, IE will still be a
problem for them. 

Exploiting this:
I can imagine that in big offices many have physical acces to machines that are
not theirs. I used to work in a company that had aprox. 500 cublicles on a floor. 
One might observe who is a BoA customer for example, and learn their lunch
habits + leaving their machines unattended (that many people really do) and
voila, there is a possibility.  
re comment 29: Form manager has nothing to do with any of this -- I don't see 
any mention of the use of form manager in this bug report.

But to answer your specific question, you are correct that form-manager does not 
save password fields.  Of course password manager does save such fields, but not 
if autocomplete=off.

Radha: yes, password fields aren't stored for save/restore or form manager, but
we store the POST data in the session history, and the password is implicitly
stored there as part of that data.  The Cache-Control headers should take care
of that, right?
The cache control headers *do not* take care of postdata in session history.
Session history holds a handle to the Postdata (nsIInputStream) for all pages
irrespective of what cache control flags the page has or any flags the password
field may have. But note that session history holds this handle in memory which
is independent of disk cache or memory cache or layout.  The cache control flags
only attribute towards saving or restoring nsILayoutHistoryState, but does
nothing for postdata. 
OK, so this is in fact a client problem as well as server.  It seems to me that
Cache-Control: no-store *should not* store the POST data, as specified in the
HTTP 1.1 RFC:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2

"If sent in a response, a cache MUST NOT store any part of either this response
or the request that elicited it."

We should not be storing POST data or (my personal opinion) even the history
data, at least the GET part.  But the GET part is debatable.
Whenever you use the back button on a cache-control site, you're prompted to
repost, right?  (I don't have a bank login to test.)  Cache-controlling the
first page out of session history isn't an attractive option, because it breaks
the back button while allowing no way to repost.  I think a site can keep
passwords from being reposted simply by making the login cgi redirect to a GET page.

I still think we should fix this bug in order to protect users of less paranoid
sites.  "Cache-control should keep all post data out of session history" should
be a separate, less severe, and possibly highrisk (due to compat) bug.
OK, so what you're saying is we need to cache the page but we need to remove the
POST information from the cache so that the user cannot log back in.  So we
either create a new Cache-Control directive, or we do this on *all* pages
resulting from posts with autocomplete=off or input type=password.  I think a
new Cache-Control directive might be better, like Cache-Control:
no-store-request or something.  But given reality we might have to do the latter
and accept that users will be totally unable to get back to these pages when
they have their cache turned off or pages expire--and this is behavior server
owners may not have anticipated.

If we do that we may as well fix no-store, which is no-cache plus
don't-store-post-data-and-stuff.  That's precisely what no-store is for.  Sites
that don't want such a paranoid behavior just use Cache-Control: no-cache
instead.  The hard part of fixing no-store will be removing the data from the
cache and showing a page explaining why nothing can be loaded, and that's what
we have to do for the proposed fix here too.
bug 157387 has a suggestion addressing this issue.
Unfortunately, that suggestion wouldn't fix this issue.  This issue is more
fundamental--the POST request *has* to contain the password.  When you save the
POST request you either save all or nothing.  If you save any less than the
entire request, then you can't use it to repost.
when do we believe we'd have a potential fix for this one?
Whiteboard: [ADT2 RTM] → [ADT2 RTM] [ETA Needed]
I have spoken to Jaime and explained several facts that make this a difficult
choice whether to put into the product:

1. We can fix this, but if we do so then an already-logged-in user will be
completely unable to go back to the first page he logged into.  This is often
the main page, the control panel if you will, so it is a real loss.
2. Sites *can* fix the problem on their side with foresight and evangelism.
3. IE already does it, so they need to fix it anyway.

Without (1), (2) and (3) would not be sufficient, but (1) means we would cause
usability problems by fixing the security problem.
Whiteboard: [ADT2 RTM] [ETA Needed] → [ADT2 RTM]
I think this bug should be opened and we should start site evangelism. The
problem  here affects IE as well as us, and most importantly it's not something
that can be automatically exploited. The only risk of having this bug open is
that someone will read it and then decide to try stealing their neighbour's bank
login. The potentially downside is fairly small I'd say.
Severity: critical → normal
Whiteboard: [ADT2 RTM] → [ADT2 RTM][sg:publish]
John, could you please file an evangelism bug that describes what sites should
be doing?

Should we do any client fix?
Group: security?
Steps to Reproduce:
1. Log in to a (php) site (with sessions)such as www.bofa.com and Bugzilla with
the <input>-types text and password
2. Log out from the site
3. Press back and then Repost
Keywords: testcase
An evang document could encourage sites to make the login cgi redirect using
GET.  (Encouraging sites to use cache-control: no-store seems like a bad idea to
me, and I don't think we'd be successful trying to introduce a new
no-store-request header.)  But since many site owners won't see the evang
document or won't go through the process of rewriting their login cgis, I still
think Mozilla should disallow reposting forms containing password fields. 
Thanks to caching, it's rare that Mozilla needs to repost a form, so I don't
think disallowing reposting password forms will cause problems.
nsbeta1-. John is overloaded with higher priority issues.
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0.1 → Future
-> me

Adding this to my 1.8 list... not sure if I'll get to it, but I think this would
be an excellent bug to resolve.
Assignee: john → darin
Severity: normal → major
Status: ASSIGNED → NEW
Priority: P2 → --
Target Milestone: Future → mozilla1.8alpha2
Target Milestone: mozilla1.8alpha2 → mozilla1.8beta
Keywords: helpwanted
I'm not going to have time to change anything here.  Patches welcome.
Target Milestone: mozilla1.8beta1 → Future
i'm fairly certain this will annoy me (and my company's product), so a way to
control the behavior (pref or build flag, pref is prefered) would be
appreciated.   changing the pref would of course not apply to things that have
already happened.
timeless: as i said before, "patches welcome" :-)
Whiteboard: [ADT2 RTM][sg:publish] → [ADT2 RTM][sg:want]
Whiteboard: [ADT2 RTM][sg:want] → [sg:want]
Assignee: darin → form-submission
QA Contact: vladimire → ian
Target Milestone: Future → ---
Whiteboard: [sg:want] → [sg:low local]
Hmm.  So can someone describe to me IE's behavior here?
IE has the same behaviour. You can use the Back button to Repost. Doing a redirect to GET after POST also prevents IE from caching the POST data.
Assignee: form-submission → nobody
QA Contact: ian → form-submission
Component: HTML: Form Submission → DOM: Core & HTML

Hey Jesse,
Can you still reproduce this issue or should we close it?

Flags: needinfo?(jruderman)

Marking this as Resolved > Incomplete since the last activity on this issue was 12 years ago and it might not be relevant anymore.
Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.