Florian Bender Reporter
	Description • 10 years ago

+++ This bug was initially created as a clone of Bug #636905 +++

Foreign-/cross-origin iFrames (et al.) should not be able to nag me unless I have interacted with them (i.e. click anywhere inside them). Specifically, they should not be able to trigger any dialogs, e.g. alert() et al., HTTP Auth. 

Doing this for same-origin iFrames will likely break a lot™.

	Tim Taubert [:ttaubert] (inactive)
	Comment 1 • 10 years ago

This is not a Firefox front-end bug, so not eligible for being in our backlog.

	:Gijs (he/him)
	Comment 2 • 10 years ago

(In reply to Florian Bender from comment #0)
> +++ This bug was initially created as a clone of Bug #636905 +++
> 
> Foreign-/cross-origin iFrames (et al.) should not be able to nag me unless I
> have interacted with them (i.e. click anywhere inside them). Specifically,
> they should not be able to trigger any dialogs, e.g. alert() et al., HTTP
> Auth. 

This would always block all toplevel HTTP auth dialogs, so that's kind of a non-starter...

	:Gijs (he/him)
	Comment 3 • 10 years ago

(In reply to :Gijs Kruitbosch from comment #2)
> (In reply to Florian Bender from comment #0)
> > +++ This bug was initially created as a clone of Bug #636905 +++
> > 
> > Foreign-/cross-origin iFrames (et al.) should not be able to nag me unless I
> > have interacted with them (i.e. click anywhere inside them). Specifically,
> > they should not be able to trigger any dialogs, e.g. alert() et al., HTTP
> > Auth. 
> 
> This would always block all toplevel HTTP auth dialogs, so that's kind of a
> non-starter...

s/toplevel//

	Jesse Ruderman
	Comment 4 • 10 years ago

We're talking about foreign, cross-origin iframes here. Why is that a non-starter?

	Jesse Ruderman
	Comment 5 • 10 years ago

How would this interact with <iframe sandbox="allow-popups">

	:Gijs (he/him)
	Comment 6 • 10 years ago

(In reply to Jesse Ruderman from comment #4)
> We're talking about foreign, cross-origin iframes here. Why is that a
> non-starter?

Why is having a cross-origin http auth'd page in an iframe "bad" in the sense that we should block the http auth dialog?

If a site is intending to use the http auth dialog in a dos-style attack, they will just use same-origin iframes - much easier.

	James Hartig
	Comment 7 • 10 years ago

If a third-party iFrame popped up an HTTP Auth window I would suspect most of my users would assume its from my site and enter their login information in the popup not realizing its going to submit to a third-party. I would hope because of at least that (not counting the annoying bit) HTTP Auth windows are included in this.

	:Gijs (he/him)
	Comment 8 • 10 years ago

(In reply to James Hartig from comment #7)
> If a third-party iFrame popped up an HTTP Auth window I would suspect most
> of my users would assume its from my site and enter their login information
> in the popup not realizing its going to submit to a third-party. I would
> hope because of at least that (not counting the annoying bit) HTTP Auth
> windows are included in this.

This is a spoofing worry, whereas the original issue here was DoS. In particular, the assertion was that you can't trust a page to do X, Y or Z if you've not interacted with it. The fundamental issue with this in the case of HTTP auth is that you'll *never* have interacted with it (as it'll come up before you even can).

It seems like if there are other concerns with doing http auth from iframes inasmuch as that's currently allowed, they should probably be a separate bug.

	Jesse Ruderman
	Comment 9 • 10 years ago

Btw, there are other bugs about blocking HTTP auth dialogs from frames: bug 647010 and bug 978471

	:Gijs (he/him)
	Comment 10 • 10 years ago

(In reply to Jesse Ruderman from comment #9)
> Btw, there are other bugs about blocking HTTP auth dialogs from frames: bug
> 647010 and bug 978471

Ah - I thought there would be, but then bugzilla search failed to find them for me... Thanks!

	:Gijs (he/him)
	Comment 11 • 9 years ago

Once bug 636905 is fixed, we track interaction state (ie "has the user interacted with this document") on a document. That should make it possible for the prompt service to implement the behaviour suggested here.

	Tanvi Vyas[:tanvi]
	Comment 12 • 7 years ago

We now have a flag for user interaction, so this should be possible.  This prevents third parties from popping up annoying dialogs that interrupt a users experience.

The specific HTTP Auth issue is separate and being discussed in bug 647010 or related bugs (tl;dr; we tried blocking http auth on subresources, it broke too much so we had to revert the page; perhaps we need to narrow it down to specific subresource content types).

(In reply to Florian Bender from comment #0)
> +++ This bug was initially created as a clone of Bug #636905 +++
> 
> Foreign-/cross-origin iFrames (et al.) should not be able to nag me unless I
> have interacted with them (i.e. click anywhere inside them). Specifically,
> they should not be able to trigger any dialogs, e.g. alert() et al., HTTP
> Auth. 
> 
> Doing this for same-origin iFrames will likely break a lot™.