[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692602#comment-16692602
]
David Smiley commented on SOLR-11501:
-------------------------------------
I should have stated it can help with keeping Solr secure. This was on my mind
when there was the hack involving activating the XMLQParserPlugin. When the
developers building the search experience choose a particular query parser to
parse _user queries_ (be it edismax or whatever), I think it is an unpleasant
surprise to learn that devious users can switch out the query parser to
something else. What I've done in apps before this point is to deliberately
prepend a space in front of the user's query to avoid such unwanted hacking.
It's true that this can be a breaking change but I thought it was acceptable
given the recent security incident and that I feel this is a bug, not a feature.
Is there a particular scenario that caused you to stumble over this (be it
tinkering or more real-world) and could you elaborate?
> Depending on the parser, QParser should not parse local-params
> --------------------------------------------------------------
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}&qq=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
