Closed
Bug 182078
Opened 22 years ago
Closed 3 years ago
Discoverability of content-blanking to detect UI spoofing
Categories
(Core :: Security, enhancement)
Core
Security
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: morse, Unassigned)
Details
One solution to the UI-spoofing problem is to have a special keypress that will
blank out all non-trusted parts of the screen display. See bug 22183 for details.
Problem with such a solution is discoverability. The obvious thing would be to
trigger the blanking by a menu item instead of by a keypress. But if the menu
itself is spoofed, the attacker has control when you click on that menu item and
he can chose to blank out whatever portion of the screen display he wants.
Another solution would be to have a menu item that tells the user about the
keypress. But then if the menu is spoofed, the atacker could have the menu item
tell the user the wrong keypress and the spoofed page would capture that
keypress and again decide what to blank out.
So this is not going to be an easy problem to solve. Assigning to UE for ideas.
Comment 1•22 years ago
|
||
reassigning to Patrice for consideration of UE ideas. I agree. This is a tough
issue to resolve with a bullet proof solution.
Assignee: lorikaplan → patricec
Some ideas:
* Special icon in the browser titlebar, click that and get a menu/whatever where
you can blank content. The bad thing is that in some situations, on some OSes,
you can spoof the titlebar (move window so that real titlebar is not visible,
but spoofed is, for example). Full screen mode would also make you vulnerable to
spoofing.
* Have an icon in the OS toolbar, like on Windows we have the QuickLaunch icon
if you have enabled that, and add a menu to blank content there. Again a page
could spoof the toolbar in fullpage mode, although the spoofed toolbar would
most likely look different.
OS: Windows NT → All
Hardware: PC → All
Reporter | ||
Comment 3•22 years ago
|
||
Keep in mind that I can always spoof a complete window, titlebar and all, by
bringing up an image within the content area. Unlike a real window, this window
could not be moved outside the original windows content area, so that would be a
clue that it is a spoof. But if the user misses that, he could be fooled by the
spoofed title bar and we've lost the game.
Comment 4•22 years ago
|
||
patricec is no longer working on this. we need to find a new owner if we think
we can find a solution.. any ideas?
Assignee: patricec → heikki
Comment 5•22 years ago
|
||
This should IMHO be WONFIXed and made public. See bug 22183 comment 75 and bug
22183 comment 79.
Updated•22 years ago
|
Whiteboard: [sg:openended]
Comment 6•20 years ago
|
||
This bug is about a *potential solution* to a problem that is already public, so
making this bug public.
Group: security
Updated•19 years ago
|
Whiteboard: [sg:openended] → [sg:investigate]
Updated•16 years ago
|
Whiteboard: [sg:investigate]
Updated•15 years ago
|
QA Contact: bsharma → toolkit
Comment 7•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:dveditz, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: hjtoi-bugzilla → nobody
Flags: needinfo?(dveditz)
Updated•3 years ago
|
Status: NEW → RESOLVED
Type: defect → enhancement
Closed: 3 years ago
Flags: needinfo?(dveditz)
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•