[
https://issues.apache.org/jira/browse/SOLR-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13137151#comment-13137151
]
Erik Hatcher commented on SOLR-2854:
------------------------------------
I've been looking at the usage of content streams and the only place I found of
concern is ExtractingDocumentLoader, which calls
stream.getName()/getSize()/getContentType() before calling getStream(), but
this seems to work fine on trunk despite the changes to lazy load the stream
and those parameters. This doesn't seem like it should work properly. No?
> 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: [email protected]
For additional commands, e-mail: [email protected]
