[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
