lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2854) Limit remote streaming to update handlers
Date Thu, 27 Oct 2011 04:03:32 GMT

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

Erik Hatcher commented on SOLR-2854:
------------------------------------

David - Thanks for the strong TDD example!  Thanks a lot for that, srsly.

Ryan - Thanks to you for the quick fix.

I tried out the test patch first, got the failure, applied Ryan's patch, test passes.  TDD
by the book.

I've committed this to trunk, with the change history log of: "Now load URL content stream
data (via stream.url) when called for during request handling, rather than loading URL content
streams automatically regardless of use."

I think the security aspect of this is a separate issue.  What we've done here is only load
URL content (file, etc content streams I double-checked, they late load already as it should)
when a component calls out for it.  So someone could still send in that same evil stream.url
to /analysis/document.  Let's spin off another issue for something like "Enable fine grained
control over allowed content streams", such that one could disable URL content streams, but
leave local file content streams possible, say.  Not sure that entirely satisfies this issue
though, as it certainly is the case that one would have situations where stream.url to load
content is really handy, but you certainly don't want any loopback (or fan-out) from malicious
data to kill a system either.  What do others think about how to address this appropriately
on the Solr side (even if that means simply making it clearer what stream.url really does
underneath)?
                
> 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_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


Mime
View raw message