seems to be blocked as popup in modern FF (71.0)
no longer issue ?

I've checked in developer channel of Firefox, but it is opening google.com and after 3 second it is asking popup for with username and password for some website.

Can you please elaborate what is the exact issue over here?

The issue is that the auth popup belongs to the attacker's tab, but it is being shown in the context of the current tab (google.com). The risk is that a user thinks that google.com is asking for credentials and enters their google password in the attacker-controlled popup. I verified this in Firefox Stable, desktop and iOS latest.

In case Michał's server ever goes away here is the testcase:

<input type=submit value="Click me" onclick="dostuff()">
<script>
  var w;

  function dostuff() {
    w = window.open('https://www.google.com', 'g');
    setTimeout(step2, 3000);
  }

  function step2() {
    w = window.open('http://199.58.85.40/a/', 'g');
  }
</script>

I'm not sure what good options we have with synchronous auth prompts, but ideally if we're navigating the top window and get a 401 we should blank the content window before showing the prompt. Clearing the addressbar isn't good enough -- if people knew they were on a particular site and the content stays the same they aren't likely to double-check the address bar.

Johann: please make sure this bug gets slotted into the right auth-prompt dependency tree and work plan

I'll clone bugs for mobile: if we're lucky Fennec/Fenix might Just Work if we fix this in Desktop but iOS certainly won't.

Paul, this will be solved by making the auth prompt tab modal as part of bug 616843, right?

So that would mean bug 613785...

P1 obviously, really bad we had this for such a long time and I hope Paul's work will rid us of these issues once and for all...

I don't know if it will. The problem is that the content is already in the tab that's going to get the tab modal prompt, and normally we don't start to replace the page content until after we get the replacement data. We will have to do something special to explicitly blank the content when a 401 response requires us to prompting the user. The modal-ness isn't the problem in this case.

We can try it out soon, but I think that associating the prompts with a browsingContext instead of just the window will do the trick. IIRC this issue was a case we specifically considered when making the new prompts, though I don't think we wrote a test for it. We should do that in this bug.

Ok, sorry, looking at this again I misunderstood the bug. I thought that the issue was with navigating your own tab to a site that triggers basic auth and thus causing the window modal prompt to be overlaid on say, google.com. But the attacker is navigating the other tab. I'm not sure if Paul's patch will solve this now, to be honest. It will definitely give us a big advantage in solving this since we can continue drawing the browser Chrome etc., but there might be additional work needed.

In addition to blanking out the content area we will definitely have to set the URL bar to display the new top level URL.

Paul, can you take a look and see what happens in this scenario when the auth prompt is tab modal?

Thanks!

Hi, sorry for the delayed reply!
I've tested it with a tab modal prompt. I'm simply switching the auth prompt call in LoginManagerAuthPrompter to tab modal:

diff --git a/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm b/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm
--- a/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm
+++ b/toolkit/components/passwordmgr/LoginManagerAuthPrompter.jsm
@@ -744,8 +744,9 @@ LoginManagerAuthPrompter.prototype = {
           this._browser
         );
       }
-      ok = Services.prompt.promptAuth(
-        this._chromeWindow,
+      ok = Services.prompt.promptAuthBC(
+        this._browser.browsingContext,
+        Services.prompt.MODAL_TYPE_TAB,
         aChannel,
         aLevel,
         aAuthInfo,

However, even though its targeting the correct browser, it will show the prompt before updating the page / URL bar. The problem persists.

I've added the PoC here as well: https://eviltrap.site/trap/http-auth-prompt-spoof/

Thanks! We should probably look at this sooner rather than later. Looking at the behavior in Chrome it seems like they update the URL bar to show the URL that's being loaded as well as blanking out the content area (and unloading the previous document).

I think that these are probably good ideas, unloading should be fine since even in the cancellation case we're going to render the contents that came with the initial 401 response and not the previous page.

Dragana/Smaug, do you have any thoughts on this from Necko/Docshell side? What would be required on your end for us to get to this state where the old document is unloaded and we can display something in the url bar before showing the basic auth prompt?

Thanks!

I do not know when the old document is unloaded, is it when it DocShell gets OnStartRequest?

The thing with 401 is that only necko see it, it is a response in between and it is handle by necko the listener og a necko channel do not see it except the prompt is canceled. I will wait for imput from Smaug and than we can figure out how to propagate 401

We are showing the tab-modal prompt during a navigation before the previous page has been unloaded.

In the demo https://eviltrap.site/trap/http-auth-prompt-spoof/, the address bar still shows example.com, even though the prompt says "eviltrap.site. This site is asking you to sign in."

Some UX options:

1. Blur example.com in the address bar. We can't show eviltrap.site in the address bar because the page is still showing example.com content.
2. Obscure example.com's page content. We already dim the page content, so obscuring it should be easy to implement.

I'll take a look, but I can't commit to a specific timeline as of now.
If feasible I'm in favor of both updating the URL-bar and blanking the content area. Might need some band-aid fix in the frontend, if we can't mess with the navigation state.

Hannah is looking into this.

Depends on D160945

Depends on D160945

Depends on D164440

Depends on D164441

Depends on D164442

Thanks for the great work on this, Hannah!
I've noticed that the current patches for the URLBar don't update the identity section yet - we still show the shield and the lock for the old site, which is confusing. Do you think we could show the fallback state, the (i) instead? Ideally we'd show the connection info from the auth request, but that might be difficult to pass to the frontend, so just a fallback state work for me. Should we file a follow-up bug for that?

Good idea, I think we should to that. Bug is filed.

https://hg.mozilla.org/mozilla-central/rev/63d1f8a23fb4
https://hg.mozilla.org/mozilla-central/rev/1bf8d8a60bb8
https://hg.mozilla.org/mozilla-central/rev/4ea502fb2357
https://hg.mozilla.org/mozilla-central/rev/e1d5f292fb83

Looking at our telemetry, in about 60% of the cases that we receive a 401, it is due to a top-level cross-domain load. This is the case that is covered by the patch, so that is good.
The case that is not covered is the 401 from a cross-domain sub-resource, which seems to be around 5%, so it might be not that severe/urgent that we are not covering this case.
(Same-domain top-level load is at 17% and same-domain sub-resource requests are at 19%)