** 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

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.

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.

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

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.

Verified with rc2 on Win XP all the scenarios in comment #4. I added a test case to litmus to cover the same scenarios.

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