Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Thu, 27 Oct 2011 16:02:32 +0000 (UTC)
From: "David Smiley (Commented) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <741408893.25137.1319731352254.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2027154311.16625.1319604572731.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-2854) Limit remote streaming to update
 handlers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

David Smiley commented on SOLR-2854:
------------------------------------

Regarding future steps to take to make Solr more secure with regards to remote streaming:  Personally, I think that, by default, the only handlers that should be able to use this are /update/ registered handlers. That makes Solr easier to secure and is also the biggest use case for this feature.  I'd like it to be clearer in solrconfig.xml exactly which handlers can use remote streaming. Presently, you have to have internal knowledge to know that /analysis/document will use it -- and that's not cool from a security perspective.  You suggested  limiting specific URLs or files or files vs URLs but I don't think that is important.
                
> Limit remote streaming to update handlers
> -----------------------------------------
>
>                 Key: SOLR-2854
>                 URL: https://issues.apache.org/jira/browse/SOLR-2854
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: David Smiley
>            Assignee: Erik Hatcher
>              Labels: security
>         Attachments: SOLR-2854-delay-stream-opening.patch, SOLR-2854-extract_fix.patch, SOLR-2854_test_remote_streaming_not_done_on_select.patch
>
>
> I think the remote streaming feature should be limited to update request processors. I'm not sure if there is even any use of using it on a /select, but even if there is, it's an unintended security risk.  Observe this URL that is roughly the equivalent of an SQL injection attack:
> http://localhost:8983/solr/select?q=*:*&indent=on&wt=ruby&rows=2&stream.url=http%3A%2F%2Flocalhost%3A8983%2Fsolr%2Fupdate%3Fcommit%3Dtruetream.body%3D%3Cdelete%3E%3Cquery%3E*%3A*%3C%2Fquery%3E%3C%2Fdelete%3E
> Yep; that's right -- this *search* deletes all the data in your Solr instance! If you blocked off access to /update* based on IP then that isn't good enough.

--
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