lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
Date Mon, 27 Feb 2012 20:55:51 GMT

    [ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13217548#comment-13217548
] 

David Smiley commented on SOLR-3161:
------------------------------------

bq. Since when did we start focusing on security in Solr's APIs?

!! (jaw dropping awe) Not soon enough!  Apparently its when I started looking into it, some
5+ years after Solr was released.  Jan, if I submitted an optional feature to Solr, perhaps
a servlet filter that errors if parameters don't meet certain patterns, would you -1 it on
principle?

Yes, steps need to be taken to lock Solr down; I don't disagree with that.  I think there
is a reasonable intuitive expectation that /select will only query data and surprisingly this
is false.  I've made this incorrect assumption both in how I've deployed Solr, how I've explained
how Solr be secured in my book, and how I've seen others explain how Solr can be secured.
 I don't think this is simply an issue of awareness (i.e. documentation).

The bare minimum I will not "-1" (not that my vote counts, I'm not a PMC member), is for "qt"
to not work with a leading slash, particularly in the default config, and right away in 3x.
 Consequently, the admin UI should not use it as such in order for the search screen to work.

So there's enough interest here to keep "qt".  Okay, fine with me.

What I would like to see is for it to be brain-dead simple to explain how a request handler
is chosen.  The <requestDispatcher handleSelect="true"> setting and <requestHandler
default="true"> setting both seem to complicate the explaination and so I think they should
go away.  All out of the box solrconfig.xml request handlers should have a name starting with
'/'.  On a request handler that supports "qt", an attribute should need to be added enableQt="true"
added to the request handler.  When qt is enabled, it dispatches to the named request handler,
but it must not start with a leading '/'.  Isn't this a simple explanation, and yet is still
customizable with 'qt'?  If agreed upon, I imagine this proposal would target 4.0.
                
> Use of 'qt' should be restricted to searching and should not start with a '/'
> -----------------------------------------------------------------------------
>
>                 Key: SOLR-3161
>                 URL: https://issues.apache.org/jira/browse/SOLR-3161
>             Project: Solr
>          Issue Type: Improvement
>          Components: search, web gui
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 3.6, 4.0
>
>
> I haven't yet looked at the code involved for suggestions here; I'm speaking based on
how I think things should work and not work, based on intuitiveness and security. In general
I feel it is best practice to use '/' leading request handler names and not use "qt", but
I don't hate it enough when used in limited (search-only) circumstances to propose its demise.
But if someone proposes its deprecation that then I am +1 for that.
> Here is my proposal:
> Solr should error if the parameter "qt" is supplied with a leading '/'. (trunk only)
> Solr should only honor "qt" if the target request handler extends solr.SearchHandler.
> The new admin UI should only use 'qt' when it has to. For the query screen, it could
present a little pop-up menu of handlers to choose from, including "/select?qt=mycustom" for
handlers that aren't named with a leading '/'. This choice should be positioned at the top.
> And before I forget, me or someone should investigate if there are any similar security
problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined
above.
> Does anyone foresee any problems with this proposal?
> On a related subject, I think the notion of a default request handler is bad - the default="true"
thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to
the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it
would be clearer to use <requestHandler name="/select" class="solr.SearchHandler"> instead
of what's there now. The delta is to put the leading '/' on this request handler name, and
remove the "default" attribute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message