Closed Bug 566893 Opened 13 years ago Closed 3 years ago

mailto: iframe opens email editor

Categories

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

defect

Tracking

()

RESOLVED DUPLICATE of bug 1517368

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
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.
> 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.
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.
Assignee: nobody → bsterne
Whiteboard: [sg: low dos] → [sg:low dos]
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?
OK, fair.  The important thing is that links and forms work.
Duplicate of this bug: 607344
Duplicate of this bug: 704019
Group: core-security
Assignee: brandon → nobody
Duplicate of this bug: 749633
Duplicate of this bug: 752265
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.
Priority: -- → P5
Component: DOM: Core & HTML → DOM: Navigation
Depends on: 670328

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.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1517368

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.

Flags: needinfo?(ehsan)

(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.

Flags: needinfo?(ehsan)
You need to log in before you can comment on or make changes to this bug.