Open
Bug 664556
Opened 14 years ago
Updated 2 years ago
Don't allow navigation from chrome to content (open content in a new tab instead)
Categories
(Firefox :: General, defect)
Tracking
()
NEW
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.
Comment 1•14 years ago
|
||
(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.
Comment 2•14 years ago
|
||
Oh, is your concern the home page then calling history.go(-1) or whatever?
Reporter | ||
Comment 3•14 years ago
|
||
Yes. Or something the home page links to or window.open()s.
Reporter | ||
Comment 4•12 years ago
|
||
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.
Reporter | ||
Comment 5•12 years ago
|
||
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?
Comment 6•12 years ago
|
||
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...
Reporter | ||
Comment 7•12 years ago
|
||
Would the non-shown page be frozen?
Comment 8•12 years ago
|
||
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?
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•