This doesn't seem like a vulnerability at all. What bad effect are you
implying here?
First of all, in those examples the XML that you "injected" is encoded in the
response, it's not actually part of the XML DOM.
And secondly, if you don't want the client to control hl.simple.pre/post you
can make them invariant in solrconfig.
And, yes, while I'm sure many folks are rendering highlighting responses
without HTML escaping to the users (in a search web app) since you want the
<em> tags to come through unescaped, that's not really the best practice... for
example, in LucidWorks Enterprise, we set the pre/post to special non-HTML
values and escape everything else and then replace our custom pre/post values
with the HTML wrapping unescaped.
I'd love to hear more about how you feel this is a security concern, along with
an example of an exploit. But I certainly would strongly recommend anyone
building apps using Solr not make Solr available outside of your known search
clients. Exposing Solr to the web without other controls in place has great
risks beyond anything that could be done with highlighting hacking I think (but
I'm open to seeing further what bad could happen here).
Erik
On Sep 20, 2011, at 04:33 , Jan Peter Stotz wrote:
> Hi.
>
> At the moment I am playing around a bit with Apache Solr with an focus on
> security. I found one very strange "feature" that allows to inject any
> text you want including xml into the response of a query.
>
> Running the example installation that comes with Solr you can test the
> following queries:
>
> http://localhost:8983/solr/select?q=*&hl.simple.pre=%3Cmyxml%3EThis%20is%
> 20injected%20content%3C/myxml%3E
>
> http://localhost:8983/solr/select?q=*&hl.simple.pre=%3C/str%3E%3C/lst%3E%
> 3C/lst%3E%3Cresult%20name=%22response%22%20numfound=%220%22%20start=%220%
> 22/%3E
>
> From what I have seen at least the two parameters "hl.simple.post" and
> "hl.simple.pre" are affected.
>
> I am now asking myself why would someone implement such a bloodcurdling
> vulnerability into a web service? Until now I haven't found an exploit
> using the parameters in a way an attacker would get an advantage. But the
> way those parameters are implemented raise some doubts on my side if
> security has been seriously taken into account while implementing Solr...
>
> Best Regards, Jan Peter Stotz
>
