XML injection interface in select servlet?

[Jan Peter Stotz <ja...@sit.fraunhofer.de>]

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 <ro...@jhu.edu>]

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.

Re: XML injection interface in select servlet?

[Erik Hatcher <er...@gmail.com>]

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
>