[
https://issues.apache.org/jira/browse/SOLR-12770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-12770:
-----------------------------------------
Description:
The "shards" parameter does not have a corresponding white list mechanism, so
it can request any URL, and the content of the HTTP response will be returned.
For legacy master/slave clusters, there is no Zookeeper to keep track of all
the nodes and shards in the cluster. So users manage the 'shards' parameter
manually for distributed search. This issue will add the option of configuring
a list of what shards can be requested.
Users will then get an explicit error response if the request includes a shard
which is not in the preconfigured whitelist, e.g. due to a typo. I think all
shards logic is handled by HttpShardHandler already so the logic should fit
nicely in that one class, configured in {{solr.xml}}.
With SolrCloud this whitelist is auto managed to match nodes in the cluster. It
is possible to disable the whitelist feature for backward compatibility. Please
see Reference Guide chapter [Distributed
Requests|https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-7.7/javadoc/distributed-requests.html#configuring-the-shardhandlerfactory].
was:
For legacy master/slave clusters, there is no Zookeeper to keep track of all
the nodes and shards in the cluster. So users manage the 'shards' parameter
manually for distributed search. This issue will add the option of configuring
a list of what shards can be requested.
Users will then get an explicit error response if the request includes a shard
which is not in the preconfigured whitelist, e.g. due to a typo. I think all
shards logic is handled by HttpShardHandler already so the logic should fit
nicely in that one class, configured in {{solr.xml}}.
With SolrCloud this whitelist is auto managed to match nodes in the cluster. It
is possible to disable the whitelist feature for backward compatibility. Please
see Reference Guide chapter [Distributed
Requests|https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-7.7/javadoc/distributed-requests.html#configuring-the-shardhandlerfactory].
> [CVE-2017-3164] Make it possible to configure a shards whitelist for
> master/slave
> ---------------------------------------------------------------------------------
>
> Key: SOLR-12770
> URL: https://issues.apache.org/jira/browse/SOLR-12770
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Affects Versions: 1.3, 1.4, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 4.0, 4.1, 4.2,
> 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10, 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 6.0,
> 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6
> Reporter: Jan Høydahl
> Assignee: Tomás Fernández Löbbe
> Priority: Major
> Labels: masterSlave
> Fix For: 7.7
>
>
> The "shards" parameter does not have a corresponding white list mechanism, so
> it can request any URL, and the content of the HTTP response will be returned.
> For legacy master/slave clusters, there is no Zookeeper to keep track of all
> the nodes and shards in the cluster. So users manage the 'shards' parameter
> manually for distributed search. This issue will add the option of
> configuring a list of what shards can be requested.
> Users will then get an explicit error response if the request includes a
> shard which is not in the preconfigured whitelist, e.g. due to a typo. I
> think all shards logic is handled by HttpShardHandler already so the logic
> should fit nicely in that one class, configured in {{solr.xml}}.
> With SolrCloud this whitelist is auto managed to match nodes in the cluster.
> It is possible to disable the whitelist feature for backward compatibility.
> Please see Reference Guide chapter [Distributed
> Requests|https://builds.apache.org/view/L/view/Lucene/job/Solr-reference-guide-7.7/javadoc/distributed-requests.html#configuring-the-shardhandlerfactory].
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
