Closed Bug 566893 Opened 14 years ago Closed 4 years ago
mailto: iframe opens email editor
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.
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.
12 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.
Priority: -- → P5
Component: DOM: Core & HTML → DOM: Navigation
Depends on: 670328
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.