mailto: iframe opens email editor
Categories
(Core :: DOM: Navigation, defect, P5)
Tracking
()
People
(Reporter: bsterne, Unassigned)
References
Details
(Keywords: sec-low, Whiteboard: [sg:low dos])
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
|
Reporter | |
Comment 1•14 years ago
|
||
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)
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•14 years ago
|
||
> 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?I don't think we want to just impose these limits on subframe navigation. Setting top.location should be equally forbidden IMHO.
|
|
||
Comment 5•14 years ago
|
||
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?
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.
|
|
Reporter | |
Updated•14 years ago
|
|
||
Updated•14 years ago
|
|
||
Comment 7•14 years ago
|
||
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•14 years ago
|
||
OK, fair. The important thing is that links and forms work.
|
||
Updated•12 years ago
|
|
|
||
Updated•12 years ago
|
|
||
Comment 13•6 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
(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.
Description
•