Closed
Bug 1310677
Opened 9 years ago
Closed 8 years ago
window.open brings focus to opened window which may cause phishing
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: cs.anurag.jain, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Steps to reproduce:
1) Open a.html
2) Navigate to 'Click Me'. In status bar you see that it will goto google.com
3) Click on it.
4) A new tab quickly opens up with fake google site. The original tab which lost focus is at original google.com
5) User would start working on fake google.com instead
Actual results:
Here in this case On clicking the hyperlink, a new tab quickly opens up with fake google site. The original tab which lost focus is at original google.com
User would start working on fake google.com instead
Expected results:
If a website is using window.open then browser should keep focus on main window instead of the window.open initiated window.
This attack becomes unnoticeable when user has already opened few tabs.
Comment 1•9 years ago
|
||
Firefox shares the same behaviour with Chrome and Safari. Anne, do you think this is the spec behaviour we'd want to revise or discuss?
Flags: needinfo?(annevk)
Comment 2•9 years ago
|
||
The specification does not prescribe which browsing context gets focus.
I think the main problem described by comment 0 is that you can easily spoof the status bar if you JavaScript enabled. I'm not sure we can really do anything to prevent that. E.g., instead of opening a new window we could just navigate the current window to "fake google", same issue.
Flags: needinfo?(annevk)
Sorry to interrupt but can we just have one simple popup displayed to user that the site is trying to open one more URL. That way user will be cautious and can actually see the address bar before continuing
Comment 4•9 years ago
|
||
(In reply to Anurag from comment #3)
> Sorry to interrupt but can we just have one simple popup displayed to user
> that the site is trying to open one more URL. That way user will be cautious
> and can actually see the address bar before continuing
I wonder if this is a solution we might consider. Mike, any opinions about the mentioned UI behaviour?
Flags: needinfo?(mconley)
Comment 5•9 years ago
|
||
This actually sounds semi-related to bug 1303838. It's kind of its opposite.
In that bug, the user is clicking on a link which is targeting a background tab, which is not then focused for the user, which is confusing.
In this bug, the user is clicking on a link which is supposed to open in the current tab (but also has the side-effect of opening a new tab).
I wonder if the best solution here is to notice that the link being clicked will also start a load in the current tab - and if that's the case, to have any tabs opened via script to open in the background.
What do you think of that, phlsa?
Flags: needinfo?(mconley) → needinfo?(philipp)
Comment 6•9 years ago
|
||
How would you detect that though? They could easily do that from a timeout as well.
Comment 7•8 years ago
|
||
I think we wouldn't really be solving the problem by dealing with window.open. If a site wanted to fake the text in the status bar text and then send the user somewhere else, setting window.location.href does that without the need for opening a new tab (see attachment).
We should probably think more about tackling this kind of phishing by making it clearer where the user is in the URL bar.
Flags: needinfo?(philipp)
Summary: window.open brings focus to opened window which may cause phising → window.open brings focus to opened window which may cause phishing
Comment 8•8 years ago
|
||
Given comment 7 I'm moving this to what I think is a better component. I'm happy to be wrong about the component, though :)
Component: DOM: Core & HTML → Tabbed Browser
Product: Core → Firefox
Comment 9•8 years ago
|
||
(In reply to Philipp Sackl [:phlsa] (Firefox UX) please use needinfo from comment #7)
> We should probably think more about tackling this kind of phishing by making
> it clearer where the user is in the URL bar.
This would make this a URL bar bug. But also, making the URL bar "clearer" about where the user is is effectively something we can do without this bug and unrelated to why it got filed.
As a general rule, the status bar can be trivially spoofed even for the current tab using various techniques, including but not limited to mousedown js handlers that modify the href, document.write calls that add a completely new page that then redirects somehow, etc. etc. We have closed such bugs because there is nothing we can specifically do about the fact that the tooltip cannot be relied upon if you are on a malicious website (e.g. bug 1310432, bug 1313828, and ultimately bug 229050 and all its dupes).
More generally, unless the actual location bar itself is lying about where the user is, there isn't really a bug to speak of: of course, foo.com could look identical to bar.com and there is nothing we can do to help the user about this beyond (a) trying to use safebrowsing's service to prevent the user from seeing the content and being 'fooled', and (b) making the URL bar as easy to use for a layperson as possible, and educating users about how to do so.
I'm going to close this bug, and if Philipp thinks it's worth it, UX can file a separate bug (in Firefox::Location Bar) about making the address bar easier to grok for non-techy people, with specific ideas about how to do that. :-)
Flags: needinfo?(philipp)
Updated•8 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Comment 10•8 years ago
|
||
I'm OK with closing this -- the work I described is fundamentally different, as you said.
Flags: needinfo?(philipp)
You need to log in
before you can comment on or make changes to this bug.
Description
•