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 12:10:32 GMT

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

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

Yonik - oops, you're right.  I was running the newly added test with -Dtestcase and just forgot
to run the full suite before committing.  Thank goodness for continuous integration build.

I committed a fix for the test, since ContentStreamBase.URLStream does not set the size until
getStream/getReader is called.  But looking at where we use stream.getSize() (and other getters)
other problems are caused as once a ContentStream is instantiated it is assumed to have a
size and a type, but this isn't the case after Ryan's patch.  Should we adjust all the places
where we use content streams to getStream/getReader before anything else?  I think so.  And
note on getStream/getReader that it must be called prior to getting any details of the stream
like size and type.
                
> 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