User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.6) Gecko/20050321 Firefox/1.0.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.6) Gecko/20050321 Firefox/1.0.2 Bookmarks can open URLs including chrome:// and javascript:. This allows to execute javascript code (e.g. to steal cookies) in the page currently displayed when opening a bookmark. If you open two bookmarks after another, and the first is a chrome:// url this allows to run arbitray code. Reproducible: Always Steps to Reproduce: I know this attack vector is mainly a theoretical since it requires a lot of user interaction, but i start this report anyway to make sure this behavior is fully intendend. There could also be easier ways of injecting malicious bookmarks with one of the many "bookmark manager" extensions, bookmark import or online bookmark sharing (again, just a theorie). While the javascript: behavior seems to be intended (since this is well known as "bookmarklets") the chrome:// access seems a little useless and only available since no check is applied at all. What about ristricting the access by default with a whitelist (http,https,ftp,ftps,javascript,etc) or at least blacklist chrome://. By blocking chrome:// i see no feature loss for 99% of the user base (tell me if i am wrong). Bookmarklets are another story. In this case the theoretical security concerns probably are not worth sacrificing such a powerfull feature (maybe add a warning dialog when adding a javascript: link?). By adding the list to about:config, extension developers could activly re-enable chrome support since they might have legitimate use of accessing chrome via a bookmark.

Sorry, forgot proof-of-concept link: http://www.mikx.de/firebooking/

javascript: is intended, all browsers do this. As for using bookmark manager extensions to take advantage of this... those are already chrome, and can do whatever they want within the app already. No big deal there. I could go either way on adding/allowing chrome:// URLs, I don't think its an exploit as much as just more surface area to potentially exploit. There might be something to be said about disallowing bookmarking of URLs from links if the link can't be accessed directly, but I don't think that represents an inherent risk, any more than any other interactive prompt does.

javascript bookmarks are not a problem, there's a whole sub-community devoted to creating and collecting nifty "bookmarklets". For Mozilla examples see http://www.squarefree.com/bookmarklets/ Running privileged chrome in a browser window is a key stepping stone for a lot of past exploits and I plan on neutering it in future versions (bug 286651).

Michael recommends to leave javascript: as-is and block chrome: by default (possible to enable with hidden config). I would agree with that, imagine a "Bookmark this" link (we knew that was possible), and there aren't many valid uses.

Should we clear the confidential flag? This is known, even somewhat desired, behavior.

*** Bug 290156 has been marked as a duplicate of this bug. ***

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.