Open Bug 664556 Opened 11 years ago Updated 8 years ago

Don't allow navigation from chrome to content (open content in a new tab instead)

Categories

(Firefox :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

()

People

(Reporter: jruderman, Unassigned)

Details

(Keywords: sec-low, Whiteboard: [sg:low])

1. Load about:permissions
2. Press Alt+Home (or Cmd+L or ...)

Result: home page loads in the same tab

Expected: open home page in a new tab

This is a security risk because it allows content to *navigate to chrome*. This can elevate a [universal-]XSS bug to a sg:critical, and it can enable clickjacking.
(In reply to comment #0)
> This is a security risk because it allows content to *navigate to chrome*.

"content" isn't doing that, the user is. I don't understand the concern.
Oh, is your concern the home page then calling history.go(-1) or whatever?
Yes. Or something the home page links to or window.open()s.
Brian Smith suggests using the opposite rule: don't allow navigating (back) from content to chrome.  Slice off the session history.  This seems more consistent with how about:newtab works.
See also bug 776167, which refers to security bugs (bug 724239, bug 769108).

UX wants to allow *users* to navigate, even if web pages can't.  But how do we allow back and forward without web pages being able to follow the WindowProxy to the chrome page?
The obvious way is by having a multiple docshells under the hood, and having the UI back/forward buttons switch between them as needed...  As in, when navigating from a content to a chrome URI and vice versa, implement it as a tab switch but make the UI look like it's the same tab. 

Not saying this is easy...
Would the non-shown page be frozen?
Presumably yes.
(In reply to Boris Zbarsky (:bz) from comment #6)
> The obvious way is by having a multiple docshells under the hood, and having
> the UI back/forward buttons switch between them as needed...  As in, when
> navigating from a content to a chrome URI and vice versa, implement it as a
> tab switch but make the UI look like it's the same tab. 
> 
> Not saying this is easy...

Would this work with the preloaded new tab page?

And if so, could other chrome URIs be preloaded to make the switch faster/snappier?
You need to log in before you can comment on or make changes to this bug.