Closed Bug 1549754 Opened 6 months ago Closed 6 months ago

Don't show "unsecure connection" warning for "mailto:" forms

Categories

(Core :: DOM: Security, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla68
Tracking Status
firefox68 --- verified

People

(Reporter: gweber, Assigned: jkt)

References

Details

(Whiteboard: [domsecurity-active])

Attachments

(1 file)

We have a contact form on the Common Voice site (https://voice.mozilla.org) which uses a a form with the action-attribute set to mailto:commonvoice@mozilla.com. When submitting the form, the user is presented with a prompt asking them to confirm that they want to use an insecure connection.
Chrome doesn't show a warning for it and my (amateur IT-Sec) intuition is that this is the right behavior, as the security of the connection is can't be determined from the mailto-link (I guess it depends on whether the mail client uses TLS?).

I've tried to recreate it in a fiddle, but in those the warning didn't appear. Is there something in the headers that might cause the warning to show up?

Here's the related Common Voice issue:
https://github.com/mozilla/voice-web/issues/1998

Any directions would be appreciated, thanks :)

Component: Security → DOM: Security

Need to check our whitelisting vs blacklisting for this. Theoretically mailto: could be mapped to an insecure http: URL, but usually it's not. Either we should check the mapping before denying it (and if there's no registered web handler it goes to a local program) or simply allow mailto: whatever it is.

(jkt is going to file a bug on making sure registerProtocolHandler() doesn't accept insecure http:// mappings as well).

Assignee: nobody → jkt
Priority: -- → P2
Whiteboard: [domsecurity-active]

I think it's not possible to set http:// as a protocol handler, the API isn't available for insecure contexts and we explicitly only allow websites to set same origin content handlers so it appears that isn't a concern.

So the work here is just permitting mailto: as a non insecure protocol for forms.

This is a pretty ancient check, predating our mixed-content-blocker implementation. It was moved to the current location in 2015 so I can't tell if the original version gave a pass to mailto: or if it was always blocked.

https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/html/HTMLFormElement.cpp#739

The "right" thing might be to look up the protocol handler if it's not one of the few manually whitelisted in this code, and then see if it's a registered web handler or an "external" handler (assume secure). Or we could just hardcode a check for "mailto:" and allow it -- much simpler. Hard to imagine posting to random protocols is enough of a thing on the web to be worth doing it the hard way.

[Edited to add] Given the assurances in comment 2 we could almost flip it and allow everything except http: (still whitelisting http: for loopback and onions). But I still lean to the more conservative option of adding one new "mailto:"

I took a somewhere inbetween approach and just whitelisted any external protocol handlers.

I'm thinking however we should actually make this a function in nsMixedContentBlocker and use this: https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/security/nsMixedContentBlocker.cpp#588-603

I suspect a form can't use moz-icon and resource so this would allowlist mailto and other external, data and javascript all as one function call.

Flags: needinfo?(ckerschb)

(In reply to Jonathan Kingston [:jkt] from comment #6)

I'm thinking however we should actually make this a function in nsMixedContentBlocker and use this: https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/security/nsMixedContentBlocker.cpp#588-603

I suspect a form can't use moz-icon and resource so this would allowlist mailto and other external, data and javascript all as one function call.

Yeah probably making this a function sounds good to me, we could then call it from the two places. I am fine with a follow up, unless you wanna do it right away. I think moz-icon should be fine to whitelist for form submissions.

Flags: needinfo?(ckerschb)
See Also: → 1550743
Pushed by jkingston@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8990b9990220
Prevent external protocol handlers from being considered insecure. r=ckerschb
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Awesome, thanks for the quick turnaround y'all :)

Flags: qe-verify+

Hi,

I tested this issue with an old Nightly build 68.0a1 (20190507214514) and I was able to reproduce it.
I also tested it using the latest Nightly build 69.0a1 (2019-06-27) and latest Beta version 68.0b13 (20190624133534) and I'm not able to reproduce the issue on Windows 10, Mac OS 10.14 and Ubuntu 18.04. Based on this I will mark the bug as Verified.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.