1490604 - Location bar spoofing when subframe requires http basic auth and top frame navigates after the dialog shows up (dialog should be closed by navigation)

Status: RESOLVED DUPLICATE of bug 656343

(Core :: Networking: HTTP, defect)

Description

[mathiaswu]

Attachment: firefox_spoof2.gif

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36
Firefox for Android

Steps to reproduce:

online demo:http://www.applestore.ac.cn/r/spoof.html
in order to make you see the whole reproduce steps , I slow down the navigation. (it could be more effective )
you can see firefox_spoof2.gif ,too.


Actual results:

http basic authentication did not disappear


Expected results:

http basic authentication should disappear after navigation

Comment 1

[:Gijs (he/him)]

This is similar to bug 656343 but subtly different. Instead of redirecting somewhere that requires http auth (and us not showing the new domain in the location bar until you authenticate), in this PoC we first open the dialog (from a subframe) and then navigate the top frame on a timeout, which should hide the dialog (but doesn't).

However... as far as I can tell (tested on mac, with Firefox 63 beta) with wireshark, we don't send the credentials the user inputs anywhere (even though a "would you like to save this password" prompt comes up - CC MattN for this). Presumably we've killed the loadgroup for the original set of requests when the toplevel document unloaded.

So, although the spoof may or may not be effective in fooling the user (we do include the requesting domain the dialog!), it can't *actually* be effective because now the page has navigated to $trustedsite (apple.com in this case) and the attacker doesn't actually get any credentials that the user may have been fooled into putting in the dialog.

Reporter, are you seeing something else?

Comment 2

[mathiaswu]

(In reply to :Gijs (he/him) from comment #1)
> This is similar to bug 656343 but subtly different. Instead of redirecting
> somewhere that requires http auth (and us not showing the new domain in the
> location bar until you authenticate), in this PoC we first open the dialog
> (from a subframe) and then navigate the top frame on a timeout, which should
> hide the dialog (but doesn't).
> 
> However... as far as I can tell (tested on mac, with Firefox 63 beta) with
> wireshark, we don't send the credentials the user inputs anywhere (even
> though a "would you like to save this password" prompt comes up - CC MattN
> for this). Presumably we've killed the loadgroup for the original set of
> requests when the toplevel document unloaded.
> 
> So, although the spoof may or may not be effective in fooling the user (we
> do include the requesting domain the dialog!), it can't *actually* be
> effective because now the page has navigated to $trustedsite (apple.com in
> this case) and the attacker doesn't actually get any credentials that the
> user may have been fooled into putting in the dialog.
> 
> Reporter, are you seeing something else?

Hi, right now I could not make a further test.
for "would you like to save this password": I can confirm that the username and password user input is saved (test on mac firefox nightly)
when you try to access http://www.applestore.ac.cn/r/401.html again
you will see the popup is automatically filled with what user input before.
if attacker ask user just to click the login button this time (user input nothing , click is a simple behavior)
then the credentials is stolen.
I'll make a further test next week on windows.

Comment 3

[mathiaswu]

the attack scenario:

1. user view www.applestore.ac.cn , open a new window and redirect to apple.com , user input password in apple.com 

2. www.applestore.ac.cn automatically refreshed , popup ask user just to click the button

from the view of user:

input password in a trusted domain "apple.com"

click button in a untrusted domain "www.applestore.ac.cn"

Comment 4

[:Gijs (he/him)]

(In reply to mathiaswu from comment #3)
> the attack scenario:
> 
> 1. user view www.applestore.ac.cn , open a new window and redirect to
> apple.com , user input password in apple.com 
> 
> 2. www.applestore.ac.cn automatically refreshed , popup ask user just to
> click the button
> 
> from the view of user:
> 
> input password in a trusted domain "apple.com"
> 
> click button in a untrusted domain "www.applestore.ac.cn"

Is this possible only if the user chooses to save the login/password combination from the dropdown that appears, or also if they don't?

Comment 5

[mathiaswu]

(In reply to :Gijs (he/him) from comment #4)
> (In reply to mathiaswu from comment #3)
> > the attack scenario:
> > 
> > 1. user view www.applestore.ac.cn , open a new window and redirect to
> > apple.com , user input password in apple.com 
> > 
> > 2. www.applestore.ac.cn automatically refreshed , popup ask user just to
> > click the button
> > 
> > from the view of user:
> > 
> > input password in a trusted domain "apple.com"
> > 
> > click button in a untrusted domain "www.applestore.ac.cn"
> 
> Is this possible only if the user chooses to save the login/password
> combination from the dropdown that appears, or also if they don't?

yes, I can confirm it would happen when user choose to save the password.

Comment 6

[mathiaswu]

(In reply to :Gijs (he/him) from comment #4)
> (In reply to mathiaswu from comment #3)
> > the attack scenario:
> > 
> > 1. user view www.applestore.ac.cn , open a new window and redirect to
> > apple.com , user input password in apple.com 
> > 
> > 2. www.applestore.ac.cn automatically refreshed , popup ask user just to
> > click the button
> > 
> > from the view of user:
> > 
> > input password in a trusted domain "apple.com"
> > 
> > click button in a untrusted domain "www.applestore.ac.cn"
> 
> Is this possible only if the user chooses to save the login/password
> combination from the dropdown that appears, or also if they don't?

Hi bro , I have found a new way to perform this attack. just reverse the step : 

online demo : http://appengine.google.com/_ah/logout?continue=https://f.3cm.me/r/401.html

the URL do not change , but 401 popup display on google.com , I found the credential is sent to attacker.

Comment 7

[mathiaswu]

and I believe this is a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=656343 , please merge this into the original report , thanks!