401 password prompt spoofing thing
Categories
(Firefox :: Security, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox111 | --- | fixed |
People
(Reporter: lcamtuf, Assigned: hpeuckmann)
References
(Blocks 1 open bug, )
Details
(Keywords: csectype-spoof, sec-want, Whiteboard: [adv-main111-])
Attachments
(5 files, 3 obsolete files)
Demo: http://lcamtuf.coredump.cx/authspoof/ You show a window-modal HTTP auth prompt visually tied to a particular tab before updating the address bar. This can have bad consequences when somebody navigates a trustworthy window to a malicious location. This seems rather undesirable. Possible fix: update the address bar and hide the original document before showing the prompt?
seems to be blocked as popup in modern FF (71.0)
no longer issue ?
Comment 2•3 years ago
|
||
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.
Comment 4•3 years ago
|
||
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.
Comment 5•3 years ago
|
||
Paul, this will be solved by making the auth prompt tab modal as part of bug 616843, right?
Comment 7•3 years ago
|
||
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...
Comment 8•3 years ago
|
||
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.
Comment 9•3 years ago
|
||
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.
Comment 10•3 years ago
|
||
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!
Comment 11•3 years ago
•
|
||
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/
Comment 12•3 years ago
|
||
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!
Comment 13•3 years ago
|
||
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
Updated•3 years ago
|
Updated•1 year ago
|
Comment 14•1 year ago
|
||
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:
- 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.
- Obscure example.com's page content. We already dim the page content, so obscuring it should be easy to implement.
Comment 15•1 year ago
|
||
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.
Updated•6 months ago
|
Assignee | ||
Comment 18•5 months ago
|
||
Assignee | ||
Comment 19•5 months ago
|
||
Depends on D160945
Updated•5 months ago
|
Assignee | ||
Comment 20•4 months ago
|
||
Depends on D160945
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Assignee | ||
Comment 21•3 months ago
|
||
Assignee | ||
Comment 22•3 months ago
|
||
Depends on D164440
Assignee | ||
Comment 23•3 months ago
|
||
Depends on D164441
Assignee | ||
Comment 24•3 months ago
|
||
Depends on D164442
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Comment 25•2 months ago
|
||
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?
Assignee | ||
Comment 26•2 months ago
|
||
Good idea, I think we should to that. Bug is filed.
Comment 27•2 months ago
|
||
Pushed by hpeuckmann@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/63d1f8a23fb4 Gray out content behind cross origin auth requests. r=pbz,Gijs,mconley https://hg.mozilla.org/integration/autoland/rev/1bf8d8a60bb8 Set URL bar state while prompt is open. r=pbz,Gijs,adw https://hg.mozilla.org/integration/autoland/rev/4ea502fb2357 Set tab title state while auth prompt is open. r=pbz,mconley,Gijs https://hg.mozilla.org/integration/autoland/rev/e1d5f292fb83 Hide authPromptSpoofing protection behind a pref. r=pbz
Comment 28•2 months ago
|
||
bugherder |
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
Updated•14 days ago
|
Description
•