User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20070219 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20070219 Firefox/126.96.36.199 From Bug #360493, during testing of the patch we exposed a password to the local screen using "mailto" as the "action" scheme. A test case will be attached. Assigning to FM instead of PM because this problem is not relevant if the "action" is already saved. Reproducible: Always Steps to Reproduce: May depend on system configuration. We used FF 188.8.131.52 and Outlook 2003. _____________ Robert Chapin Chapin Information Services, Inc.
Note the encryption warning issued by the test case is due to the file being hosted on https. Save and test elsewhere to confirm.
So, I see two scenarios where this bug is relevant: 1) The "Whoops, my admin is dumb and is sending sensitive data through a mailto." That is, there isn't malicious intent, but there's the potential for badness. 2) The Attacker-creates-mailto-form scenario. This is much more nefarious and quite plausible - a phishing form could mailto, for instance. If the scenario we're concerned with is #2 though, this bug seems unlikely to offer any real protection, since an attacker will just style a non-password input to look like a password field. They won't tip their hand. An attacker could also do lots of other things to get that password, of course, and I know you've opened bugs tracking some of those, but the question is whether this bug adds anything to the user's safety. For scenario #2 I don't think it does. Are we talking about scenario #1 only then?
I think there is a common-sense factor about protecting both scenarios. Password fields can protect PINs, SSNs, credit card numbers, etc. The actual reason behind the action being mailto only figures into the severity of the bug.
Fwiw, IE7 gives this dialog when submitting with the testcase: " This form is being submitted using e-mail. Submitting this form will reveal your e-mail address to the recipient, and will send the form data without encrypting it for privacy. You may continue or cancel this submission. " So maybe Firefox should do something similar?
I guess not is the last chance to try and do anything for fx3. should we try?
Not blocking, far too late for changes of this type.
I don't think there's much value in warning the user about submitting a password over email. We could quibble about the details, but to a gross approximation email is no different than HTTP -- both are an unencrypted, unauthenticated path. Anyone between the user and the end recipient could monitor and/or modify the data without being detected. We've already removed the warnings about submitting unencrypted forms, because they end up just being confusing noise to users. So it's not worse than that. [It's arguably better, since the form submission just opens a message in your email client, so users still have the opportunity to change their mind before clicking "send".]