User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-CH; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-CH; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Due to Bug 290037 local search doesn't work in Firefox >= 1.0.3. This means that searchplugins like : <search name="...." action="file://///machine/search.html" or : <search name="...." action="file://d:/machine/search.html" just stopped working when switching to Firefox 1.0.3. This is a major problem for companies that developped searchplugins based on the file:// protocol. Reproducible: Always Steps to Reproduce: File protocol should be re-enabled or at leaste there should be a pref to enable it if needed.

Yes ! Why block local URl in search plugins ??? It s important for development into a compagny or univerties (...) to keep local URL (or not)in a search plugin. Perhaps create an option (in about:config) to check YES or NO this security limitation...

I'm not sure this is going to be reenabled, but we should suggest a migration option, maybe indicate how to create an extension to do such searches ?

I'm not against whitelisting file:, which would be a simple change to the patch in bug 290037 - !StringBeginsWith(action, NS_LITERAL_STRING("https:"))) + !StringBeginsWith(action, NS_LITERAL_STRING("https:")) && + !StringBeginsWith(action, NS_LITERAL_STRING("file:"))) The file: could point back at the attacker's server, but if someone convinces you to install their search plugins in order to spy on your search requests they could do that just as easily with http: I'll nominate for 1.0.5 because it's a regression, but likely only security fixes will be taken for the branch.

Comment on attachment 184346 [details] [diff] [review] allow file: as a search plugin action Hmm, you'd think that after all the issues people constantly have with file: uris, they would stop using them and just set up an intranet web server. r=caillon

Not holding up a 1.0.x security release

This regression is a security problem : We use some local search plugins in the search bar in my compagny into Firefox 1.0.2, we can't upgrade to FF 1.0.4 because this bug. So we have some security problems (resolved in upgrading Firefox 1.0.4) ! Same problems in university, we need used 2 Firefox versions, the first one FF 1.0.2 for internal use only (with local search), and FF 1.0.4 for Net use (with all recent securities)...... VERY BAD REGRESSION.

Comment on attachment 184346 [details] [diff] [review] allow file: as a search plugin action 1.0.5 has already shipped; unsetting approval request.

Not going to block 1.8.1 for this bug. It looks like there hasn't been interest in landing the current patch on the trunk even.

Unless this is a SeaMonkey bug, this has already been FIXED. The new Firefox search service that is shipping in Firefox 2 has no such restrictions.

This was filed against Firefox, so moving there.

Turns out that the Firefox 2 search service still has this bug.

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

This doesn't seem useful, in general. One can run a local webserver easily enough, which is more likely the case for testing a search service, vs. a static file on disk.

Yes it's easy to run and use searchplugin with a local web server, but this restriction impose a web server environment. For example, in my university, we need to distribute some portables CD-ROM including lessons in ".htlm" format. So it's not possible for all students to use webserver to explore these portable distributions. Such a shame . Firefox it's not restricted just for net or local server environment, why not to have choice with an "about:config" option ?

What in general is speaking against allowing "file" or at least "chrome" as a scheme compared to "http"? Why restrict the scheme anyway? In the end, all that the nsSearchService does, is constructing a URL based on the search-terms and the URL-template defined in the SearchPlugin ... and load this URL in the browser. I, f. ex., defined my own ProtocolHandler in an extension and would love to use a search-plugin for my own scheme. I am eager to know the reasons for this restriction. Thanks!

[Update] I understand blocking "javascript:" and maybe data (because it can be used for javascript as well) as both open up security issues. Can't we just check for those and allow everything else? Cheers.

If you combine the ability to cause certain URIs to be loaded (i.e. using a search plugin that you've convinced the user to install) with an XSS vulnerability, then you have a potentially serious problem. Granted, that scenario is a bit far fetched and unlikely to be a problem in practice. But no one has come up with very compelling use cases for allowing additional schemes that can't be addressed in other ways, so from my point of view there's little benefit in loosening the restrictions.

But to be able to load certain URI's, Firefox needs to know the protocol. And custom protocol-handlers can only be added via extension. So in your scenario the bad guy has to convince the user to install the extension AND the search plugin. If he got the user to install his extension, he can already do any harm he wants - he doesn't need an additional search-plugin and any XSS vulnerability. Even if you don't want to allow all protocols, what speaks against adding "chrome"? Thanks for your response!

[Update - again] I was partially wrong about the ProtocolHandlers, as the bad guy could also convince the user to install a Web-ProtocolHandler (+ the search-plugin; a lot of convincing to do for the poor guy). Anyway, you could check if the search-plugin url leads to a Web-ProtocolHandler and not allow it in that case. We would need to add a member to nsIDOMClientInformation to retrieve a list of registered Web-ProtocolHandler's. That's really a bit of work (although it shouldn't be too much), so let's first take a look at allowing "chrome" for which you also would need an extension to be able to do harm. Cheers.

I'm not worried about custom protocol handlers, I'm worried about some of our defaults. Being able to load chrome:// or moz-image:// or any number of other built-in handlers could be problematic.

Oh. Now you are surprising me! ;) The only situation I can think of, where a SearchPlugin can do harm by using a "chrome"-URL is, when there is already an existing standard-Firefox xul-file or whatever that will do this harm when being opened in the browser. And for moz-icon, I can't even imagine anything problematic when opening such a URL. What kind of security issues are you thinking about? Thanks for this discussion! Cheers, André

As I mentioned earlier, the ability to load chrome:// URIs combined with an XSS vulnerability. I don't really want to dive into the security implications here - perhaps you should focus on describing what you want to accomplish that requires this bug to be fixed :)

Alright, that might be easier. :) For my extension I basically need a searchplugin that opens up a page which has chrome-access. that's why i have written my own protocolhandler that will create a xul-page based on the input it gets (the search-term). There are some more reasons for this protocolhandler to exist, but they are not important here ... So what i am trying to accomplish, is to be able to use this protocol in the searchplugin: <Url type="text/html" method="GET" template="my-search:{searchTerms}"/> Unfortunately nsSearchService has the hard-coded restriction for "http" and "https" in it. Comment #15 already proposed to have a about:config-preference for additional allowed protocols. Makes sense to me. Alternatively nsSearchService could also get a new method addAllowedProtocol("my-search"), which the extension-developer can call on startup. In both cases you could still forbid some default-protocols like chrome, if you really really don't want those to be usable. What do you think? Cheers.