XML injection interface in select servlet?

[Jan Peter Stotz]

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

Re: XML injection interface in select servlet?

[Erik Hatcher]

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
 

Re: XML injection interface in select servlet?

[Jonathan Rochkind]

On Sep 20, 2011, at 04:33 , Jan Peter Stotz wrote:



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...


Solr committers can correct me if I'm wrong, but my impression is that 
the Solr API itself is generally _not_ intended to be exposed to the 
world. It's expected to be protected behind a firewall, accessed by 
trusted applications.


People periodically post to this list planning on exposing it to the 
world anyway; but my impression is there may be all kinds of security 
problems there, as well as DoS possibilities, etc.


So I think it may be safe to say that security has not been seriously 
taken into account -- if you mean security on a Solr instance which has 
it's entire API exposed publically to the world.  I don't think that's 
the intended use case.