566893 - mailto: iframe opens email editor

Status: RESOLVED DUPLICATE of bug 1517368

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

Description

[Brandon Sterne (:bsterne)]

The nsNoDataProtocolContentPolicy doesn't block TYPE_SUBDOCUMENT, so sites embedding <iframe src="mailto:foo"> can force the mail handling application to open.

For reasons why, see the three comments in bug 181860 starting with:
https://bugzilla.mozilla.org/show_bug.cgi?id=181860#c50

Comment 1

[Brandon Sterne (:bsterne)]

MustLive (copied) also reported that this technique can be used in a loop to exhaust system resources:
http://translate.google.com/translate?hl=en&u=http://websecurity.com.ua/4206/&sl=uk&tl=en

(btw, this bug can probably be opened up, since bug 181860 is already open, but I just wanted to be on the safe side)

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'd love to make it so that mailto: links, and other protocol handlers, are only activated if the navigation is the result of a 'trusted' navigation. I.e. if it is as a result of the user clicking a link or submitting a form.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> I.e. if it is as a result of the user clicking a link or submitting a form.

We could enforce this in docshell, no?  We know whether we're a subframe, we know whethe it's a link click, and we should be able to get info on protocol handlers if we try; certainly for something like mailto: where there's the "no data" flag.

Want a patch to do that?

Note that this would break window.location sets to mailto: URIs on subframes, though.  That should be ok, right?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't think we want to just impose these limits on subframe navigation. Setting top.location should be equally forbidden IMHO.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Sure, that's clearly possible if the subframe thing is... just one less check.  Is there any value to treating this like we do popups, or should we just block it period?

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, treating it as a popup sounds good. I'm definitely worried about breaking people here.

We do need to tighten up our popup story, which would then automatically catch this too, which IMHO is a good thing.

Comment 7

[Johnny Stenback (:jst)]

Treating it like we do popups wouldn't help if a tight loop is triggered from within a click action tho. Seems to me that we need to identify load requests that are initiated by untrusted script and block no-data protocol loads at that point? No?

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK, fair.  The important thing is that links and forms work.

Comment 13

[Firefox Bug Husbandry Bot]

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

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 14

[(no longer active)]

There has been some recent work in this area. Bug 167475 blocked no-data protocols loaded in iframes. After that, bug 1517368 updated our loading path for no-data protocols in iframes to honour the rules of the pop-up blocker. Then bug 1514547 made us load the first no-data protocol URL in an iframe when we'd normally disallow pop-ups for web compatibility reasons.

Right now if you have a web page with an iframe pointing to a mailto: URL, the mail application is opened because of bug 1514547, but the page won't be able to open more than one of such URLs. So I'm inclined to mark this as a dupe of bug 1517368.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Hmm. So the roblox thing did the "no user interaction at all other than pageload, but we want to launch an external app" thing? There's no clear analysis of their code that I see in bug 1514547, so just trying to make sure I understand.

Comment 16

[(no longer active)]

(In reply to Boris Zbarsky [:bzbarsky] from comment #15)

Hmm. So the roblox thing did the "no user interaction at all other than pageload, but we want to launch an external app" thing? There's no clear analysis of their code that I see in bug 1514547, so just trying to make sure I understand.

Yeah, the user would go on a page which had an iframe linking to their custom protocol handler which would launch their application by setting an iframe src to something like roblox-player:1+launchmode:play+gameinfo:9B4063B66491C8657C46650ABEB53531328C947BFD4E265CC70741CF38787366870826E6D87BACC8DD64C9459FB0EF94BA8E79E424FAE59945DC95D072F1C32A82F73B7F2C3D32A4DB8E31AF6778B855146340D8A4E3784FFE710891E1F1C21173444FCCA103C30DD02481674CF427BAF12FFE96F0BD6145B2CE5D42EBC40BE26965273E367976F133F2AB8D512EF51E20FCD0FDD64520664314CA00880390DA73DDE66F+launchtime:1583938787901+placelauncherurl:https%3A%2F%2Fassetgame.roblox.com%2Fgame%2FPlaceLauncher.ashx%3Frequest%3DRequestGame%26browserTrackerId%3D49013587989%26placeId%3D1262182609%26isPlayTogetherGame%3Dfalse+browsertrackerid:49013587989+robloxLocale:en_us+gameLocale:en_us.