Open Bug 1383402 Opened 8 years ago Updated 6 months ago

Temporary addressbar spoof by copy/pasting url for slow/unreachable port into location bar

Categories

(Firefox :: Address Bar, defect, P5)

54 Branch
defect

Tracking

()

Tracking Status
firefox57 --- fix-optional

People

(Reporter: Laraweron, Unassigned)

References

Details

(Keywords: csectype-spoof)

Attachments

(2 files)

Attached file poc.html
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170628075643 Steps to reproduce: Open attach poc.html Actual results: Go to website with wrong port causing the large response time.When you load the page, it is possible to spoof content. Bug occurs in the 54 version of Firefox 55 and 56 versions, the content of the page does not change
This affects other browsers just the same, and is really similar to bug 791597. I'm not convinced there's anything else we can reasonably do here, or that there is a benefit to keeping this hidden. Dan?
Component: Untriaged → Location Bar
Flags: needinfo?(dveditz)
Keywords: csectype-spoof
Summary: Temporary addressbar spoof → Temporary addressbar spoof by copy/pasting url for slow/unreachable port into location bar
Note In the beta version of firefox, the bug is not so obvious. Therefore, i believe that the bug can be fixed.
(In reply to Raphael from comment #2) > Note In the beta version of firefox, the bug is not so obvious. Without more details, I don't understand what this sentence means, much like the meaning of this: (In reply to Raphael from comment #0) > Bug occurs in the 54 version of Firefox > 55 and 56 versions, the content of the page does not change is not obvious to me. Can you be more explicit?
Flags: needinfo?(Laraweron)
Attached image firefox
Firefox Nightly, resets value the body.innerHTML.
Flags: needinfo?(Laraweron)
(In reply to Raphael from comment #4) > Created attachment 8889405 [details] > firefox > > Firefox Nightly, resets value the body.innerHTML. It doesn't for me, the testcase works the same way on 56 and shows the "spoof" text. In any case, I expect the only difference here are issues with the poc's methods of detecting navigation and then writing to the document. That has nothing to do with the core issue of the user attempting to navigate to a URL that is so slow to respond that the current page has time to change content and "abuse" the new URL that is already displayed in the location bar. Removing the new URL sooner would lose user data. The only real option here is separating the indicator of the current domain and the inputbox (e.g. by swapping in the user-edited value on focus or something) but that has other issues in terms of user expectations etc. We have other bugs on file about this as well.
I noticed the following, in Firefox stable, the timeout occurs after the minute of the page load starts, this is normal browser behavior, but in Firefox Nightly there is another special feature, if during the page loading press Esc, the address line value is not reset. I want to try to implement the proof of concept for Firefox Nightly, when I load the page with the wrong port, the connection is reset, after that the event fires "window.stop" and display my code. (In reply to :Gijs from comment #5) > It doesn't for me, the testcase works the same way on 56 and shows the > "spoof" text. You said that in version 56 of the Poc browser you are working, write what you use operating system ?
(In reply to Raphael from comment #6) > in Firefox Nightly there is another special feature, if during the page loading > press Esc, the address line value is not reset. Old and new versions of Firefox behave the same: ESC should stop the load and revert the addressbar to the real URL of the page. worksforme on Mac and Windows, and on nightly, release, and ESR52.x The visual clues are somewhat subtle, but the throbber keeps throbbing and the lock icon never appears for a secure site (an insecure site you can never trust anyway). We don't need to keep this hidden.
Group: firefox-core-security
Flags: needinfo?(dveditz)
Priority: -- → P5
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
Duplicate of this bug: 1907399
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: