Closed Bug 405926 Opened 12 years ago Closed 12 years ago

ensure that javascript and data URIs in the bookmarks/history sidebars execute in content context

Categories

(Firefox :: Bookmarks & History, defect, P2)

defect

Tracking

()

VERIFIED FIXED
Firefox 3

People

(Reporter: dietrich, Assigned: dietrich)

References

Details

(Whiteboard: [swag: 1d][sg:investigate] (prevent potential critical/high bugs))

** Vulnerable in the past
** Executes in chrome (plugged in 2 and 3)
** TODO: confirm js and data URIs not in places UIs
** http://mxr.mozilla.org/seamonkey/ident?i=PU_checkURLSecurity
** http://mxr.mozilla.org/seamonkey/source/browser/components/places/content/utils.js#1251
Blocks: 375898
IMO:
* javascript: URLs from bookmarks should execute in the context of the current page.
* data: and javascript: URLs from history should get some kind of new security context.
* data: URLs from bookmarks should probably be treated the same way as data: URLs from history rather than executing in the context of the current page.  I don't know what Firefox 2 did for them.
Since this is a dependency of bug 375898, marking P2 so it stays on our radar for Fx3 triage/tracking.
Flags: blocking-firefox3?
Priority: -- → P2
Target Milestone: --- → Firefox 3 beta4
Whiteboard: [sg:investigate] (prevent potential critical/sg:high or sg:critical
Whiteboard: [sg:investigate] (prevent potential critical/sg:high or sg:critical → [sg:investigate] (prevent potential critical/high bugs)
Flags: blocking-firefox3? → blocking-firefox3+
Target Milestone: Firefox 3 beta4 → Firefox 3
Assignee: nobody → dietrich
From Jesse's comment in bug 305692 comment 3:
* For data: URLs, the URL should just be loaded with a null principle.

Bug 417798 allowed javascript: uris to show up in the location bar autocomplete only if the user explicitly types out javascript: as the first term.
Depends on: 305692, 417798
Whiteboard: [sg:investigate] (prevent potential critical/high bugs) → [swag: 1d][sg:investigate] (prevent potential critical/high bugs)
Jesse, do you know if there are any automated tests in the tree for privilege escalation like this scenario?

Here's what I've tested manually:

configurations:
- normal
- "open in sidebar" is checked

scenarios:
- open from toolbar
- open from sidebar
- open from organizer
- open from menu
- open in new window via context menu
- open in new tab via context menu
- open via keyword in location bar
- open via autocomplete in location bar
Status: NEW → ASSIGNED
Sorry, I don't know anything about automated tests for privilege escalation bugs, or automated tests for Places.
There are two central APIs that Places uses to open bookmark/history URIs.

The first is PlacesUIUtils.openNodeIn():

http://mxr.mozilla.org/seamonkey/search?find=%2Fbrowser%2Fcomponents%2Fplaces%2Fcontent%2F&string=++opennodein

Which uses these APIs to open URLs from query result nodes:

For "open in sidebar":
- sidebar.contentWindow.loadWebPanel
- http://mxr.mozilla.org/seamonkey/source/browser/base/content/web-panels.js#96

Otherwise, everything is routed through utilityOverlay.js::openUILinkIn()
- http://mxr.mozilla.org/seamonkey/source/browser/base/content/utilityOverlay.js#198

When saving:
- saveURL()
- http://mxr.mozilla.org/seamonkey/source/toolkit/content/contentAreaUtils.js#88

For opening in a new window:
- window.openDialog() to browser.xul, pass url

For opening in the current window:
- window.loadURI();

For opening in a new tab:
- tabbrowser.loadOneTab();
The second API is PlacesUIUtils._openTabset():

http://mxr.mozilla.org/seamonkey/search?find=%2Fbrowser%2Fcomponents%2Fplaces%2Fcontent%2F&string=_opentabset

For opening in a new window:
- window.openDialog() to browser.xul, pass urls joined by "|"

Otherwise it uses:
- tabbrowser.loadTabs()

I'm pretty satisfied with the analysis here.  We really want a way of ensuring this doesn't change in the future, but that's not a problem I'm going to block the release on.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Blocks: 429167
Verified with rc2 on Win XP all the scenarios in comment #4.  I added a test case to litmus to cover the same scenarios.
Status: RESOLVED → VERIFIED
Flags: in-litmus+
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.