1313916 - For a toplevel load where the authentication prompt is dismissed we don't unload the current page in some circumstances

Status: UNCONFIRMED

(Core :: Networking: HTTP, defect, P3)

Description

[Jose María Acuña]

Attachment: Vídeo demostrativo

Introduzca esta url en la barra de navegación de Mozilla Firefox:

data:text/html,<a href="http://feeds.feedburner.com/GoogleInbox" onclick="var x = open(this.href,'gtn-roster-iframe-id','toolbar=0,location=0,directories=0,status=0,menubar=0,scrollbars=1,resizable=1,width=750,height=330'); x.moveTo((top.screen.width-750)/2, (top.screen.height-330)/2 ); x.document.body.innerHTML += '<iframe src=http://www.elandroidelibre.com/wp-content/uploads/2014/10/inbox-gmail.jpg onload=alert(prompt(\'Email/Password\')) style=height:100%;width:100%;border:0;position:fixed;top:0;left:0;overflow:hidden></iframe>'; return false;">Authentication</a>

Si el usuario no recuerda el usuario/contraseña de acceso al portal web al pulsar el botón cancerlar, se le pregunta por la dirección de email y su contraseña como alternativa (el texto de esta ventana se puede personalizar para parecer más creible).

En principio, el ejemplo es válido para cualquier dominio de autenticación de windows.
Otro ejemplo: https://chromium.googlesource.com/chromium?format=JSON

* Adjunto vídeo demostrativo

Comment 1

[Jeff Bryner [:jeff] (use NEEDINFO 😉)]

Not a website vulnerability, moved to firefox for triage.

Comment 2

[:Gijs (he/him)]

Google translate of comment #0:

---
Enter this URL in the navigation bar Mozilla Firefox:

<snip>

If the user does not remember the username / password access to the website by pressing the "cancel" button, asked for the email address and password as an alternative (the text of this window can be customized to look more credible).

In principle, the example applies to any domain authentication windows.
Another example https://chromium.googlesource.com/chromium?format=JSON

---

Note: the dialog is not a "Windows authentication system" - it is an HTTP authentication dialog, and unrelated to the Windows OS.


The authentication window already shows the domain for which credentials are requested. The "alternative" password prompt isn't any more convincing than if you showed it on a general spoof page. To steal the passwords through the http auth dialog you would have to control the target domain which would then be different from the page/iframe content you're loading, and the URL bar correctly displays about:blank as that's the controlling page at that time. As a result, I don't see that this is convincing or actionable enough to do much with, so I'm unhiding the bug. I would suggest closing INVALID, but I leave it up to Al/Dan to make further decisions here.

Comment 3

[Jose María Acuña]

I agree Gijs Kruitbosch,
but there is something very disturbing for me:

- Firefox locks the window with a modal dialog between the authentication request and the server response. No other browser lets do it.

Comment 4

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #3)
> I agree Gijs Kruitbosch,
> but there is something very disturbing for me:
> 
> - Firefox locks the window with a modal dialog between the authentication
> request and the server response. No other browser lets do it.

That is bug 613785.

Comment 5

[Jose María Acuña]

Allow me to insist,
but if I put title to the window (the domain name) and add an image of your domain, spoof is almost guaranteed.
I would like to know what percentage of active members of the web are aware that "about: blank" is not a valid protocol domains :)

Image1:

https://drive.google.com/file/d/0B5G3cbs08P16cmlSMWoyZHRKeUk/view

Image2:

https://drive.google.com/file/d/0B5G3cbs08P16QzQxUlpScTNsWjg/view

Video:

https://drive.google.com/file/d/0B5G3cbs08P16V0RBaTdHVXNiNUU/view

Regards!

Comment 6

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #5)
> Allow me to insist,
> but if I put title to the window (the domain name) and add an image of your
> domain, spoof is almost guaranteed.
> I would like to know what percentage of active members of the web are aware
> that "about: blank" is not a valid protocol domains :)

Then you could avoid all of the http auth window stuff and just window.open("about:blank", "_blank", "height=200"), and manipulate the window that that returns to have login inputs that you read.

People not understanding "about:blank" and showing something else is bug 1297008. Note that all other browsers do the same thing (ie show "about:blank").

Comment 7

[Jose María Acuña]

Yes but I do not speak of a general behavior. In this particular case:
- other browsers, popup alert intercept and cancel (not displayed). Firefox leave this door open.

Comment 8

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #7)
> In this particular case:
> - other browsers, popup alert intercept and cancel (not displayed). Firefox
> leave this door open.

I do not understand what this sentence means. Could you rephrase?

Comment 9

[Jose María Acuña]

I am sorry.
Internet Explorer, Google Chrome, Opera, do not show the modal dialog 'window.prompt' so there is no possibility of spoof. It only happens in Firefox.

Comment 10

[:Gijs (he/him)]

OK, I think I understand.

Boris, any idea why in e.g. Chrome the opener is not allowed to modify the about:blank document of the opened window, trigger onload, and queue a prompt, whereas all of that succeeds in Firefox?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> why in e.g. Chrome the opener is not allowed to modify the about:blank document of the opened window
> trigger onload, and queue a prompt

Er... why do you think it's not?  In Chrome, this is the sequence of events I see, on Mac:

1)  window.open causes a new window to be opened.
2)  The prompt triggered by the prompt() call from the subframe load event handler is shown.
3)  The prompt from prompt() is hidden and the authentication dialog
    for http://feeds.feedburner.com/GoogleInbox is shown.

If I replace "http://feeds.feedburner.com/GoogleInbox" with "http://software.hixie.ch/utilities/cgi/test-tools/delayed-file?pause=2&mime=text%2Fplain&text=Hey+there" in the anchor href, then you can very clearly see the prompt() call showing a dialog in Chrome.  Of course if the subframe load races with the main page load and the main page wins the ref there won't be any prompt, because the whole thing, including the subframe, will be unloaded before the subframe load event fires.

Comment 12

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #11)
> > why in e.g. Chrome the opener is not allowed to modify the about:blank document of the opened window
> > trigger onload, and queue a prompt
> 
> Er... why do you think it's not?  In Chrome, this is the sequence of events
> I see, on Mac:
> 
> 1)  window.open causes a new window to be opened.
> 2)  The prompt triggered by the prompt() call from the subframe load event
> handler is shown.
> 3)  The prompt from prompt() is hidden and the authentication dialog
>     for http://feeds.feedburner.com/GoogleInbox is shown.

OK. The prompt() disappeared so quickly when I ran this initially that I didn't think it got shown at all. Trying it a few more times, I see a flash that is presumably this prompt.

> If I replace "http://feeds.feedburner.com/GoogleInbox" with
> "http://software.hixie.ch/utilities/cgi/test-tools/delayed-
> file?pause=2&mime=text%2Fplain&text=Hey+there" in the anchor href, then you
> can very clearly see the prompt() call showing a dialog in Chrome.  Of
> course if the subframe load races with the main page load and the main page
> wins the ref there won't be any prompt, because the whole thing, including
> the subframe, will be unloaded before the subframe load event fires.

It seems in Gecko, we manage to show the (tab-modal) prompt while the modal auth dialog is up, the http auth prompt does not dismiss the JS prompt() or force the unload of the original page. Only after the JS on the about:blank page has run to completion do we show the 401 error page from feedburner.

Unsure if this is just a side-effect of having the http auth prompt be app-modal and the prompt() tab-modal, and if there's anything we can/should do here to avoid showing the prompt() (ie force the unload of the page and abort the JS onload script/prompt that's running).

Comment 13

[Jose María Acuña]

A new unwanted behavior:
- you can block the execution of any web page.

Note: Chrome blocks in the current tab

Video demonstration: https://drive.google.com/file/d/0B5G3cbs08P16d1VwWFppWHFFWUU/view

Html example:

<html>
<head><title>Page Locking</title></head>
<body>

<a href="https://www.mozilla.org/en-US/firefox/new" onclick="
	var x = top.open(this.href,window,'');
	setTimeout(function(){
		x.document.body.outerHTML += '\
		<iframe src=http://www.adslzone.net/app/uploads/2016/02/mozilla-firefox-evitar-rastreo.jpg onload=parent.top.opener.alert(\'blocking\')\
			style=position:fixed;top:0;left:0;width:100%;height:100%;border:0></iframe>';
	}, 0);
	return false;">
	Page Locking
</a>

</body>
</html>

Comment 14

[:Gijs (he/him)]

(In reply to Jose María Acuña from comment #13)
> A new unwanted behavior:
> - you can block the execution of any web page.
> 
> Note: Chrome blocks in the current tab
> 
> Video demonstration:
> https://drive.google.com/file/d/0B5G3cbs08P16d1VwWFppWHFFWUU/view
> 
> Html example:
> <snip>

This is a different issue. Please file a new bug.

Comment 15

[Jose María Acuña]

Ok, thanks.

Comment 16

[Daniel Veditz [:dveditz]]

This does not qualify for a bug bounty

Comment 17

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #12)
> > If I replace "http://feeds.feedburner.com/GoogleInbox" with
> > "http://software.hixie.ch/utilities/cgi/test-tools/delayed-
> > file?pause=2&mime=text%2Fplain&text=Hey+there" in the anchor href, then you
> > can very clearly see the prompt() call showing a dialog in Chrome.  Of
> > course if the subframe load races with the main page load and the main page
> > wins the ref there won't be any prompt, because the whole thing, including
> > the subframe, will be unloaded before the subframe load event fires.
> 
> It seems in Gecko, we manage to show the (tab-modal) prompt while the modal
> auth dialog is up, the http auth prompt does not dismiss the JS prompt() or
> force the unload of the original page. Only after the JS on the about:blank
> page has run to completion do we show the 401 error page from feedburner.
> 
> Unsure if this is just a side-effect of having the http auth prompt be
> app-modal and the prompt() tab-modal, and if there's anything we can/should
> do here to avoid showing the prompt() (ie force the unload of the page and
> abort the JS onload script/prompt that's running).

Boris, do you know if this is something we can/should fix (or if I'm still misunderstanding) and if so, what would be a suitable component?

Comment 18

[Boris Zbarsky [:bzbarsky]]

It really depends on the behavior we want here.  Apart from moving the auth prompt to be tab-modal, we could take down all tab-modals parented to the relevant window before bringing up the auth prompt, and ensure that new ones can't be put up, right?

Comment 19

[:Gijs (he/him)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #18)
> It really depends on the behavior we want here.  Apart from moving the auth
> prompt to be tab-modal, we could take down all tab-modals parented to the
> relevant window before bringing up the auth prompt, and ensure that new ones
> can't be put up, right?

Yes, though I'm not sure where to do that off-hand, I guess that would mean this would need to be fixed in networking...

Comment 20

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Is PSM the right component here? My understanding was the HTTP auth code was spread around necko, docshell, and maybe browser/toolkit?

Comment 21

[u408661]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #20)
> Is PSM the right component here? My understanding was the HTTP auth code was
> spread around necko, docshell, and maybe browser/toolkit?

Argh, sorry. I had tentatively made that change, but then re-thought myself and realized this probably does belong in necko (or one of those others) - hence the necko-backlog in the whiteboard. Obviously I didn't fully roll back my transaction, though, before committing the new one :)

Comment 22

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 23

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258