Protection against cross scripting attacks (xss) in Elastic Search server?

Elastic Stack Elasticsearch
1

Hi All,

Issue: elastic search server (port:9200) is prone to the XSS
vulnerability.

*version: *0.19.8

Environment: RHEL 5.10

Vulnerability Description:
The elastic search server fails to adequately sanitize request strings of
malicious JavaScript.
So, an attacker may be able to cause arbitrary HTML and script code to be
executed in a user's browser within the security context of the affected
site.

The request string used to detect this flaw was :
/scripts/uw12snbk.asp?

The output was :

HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Content-Type: text/plain; charset=UTF-8
Content-Length: 108

No handler found for this uri
[/scripts/uw12snbk.asp?] and method [GET]

So, Is there a Elastic Search server configuration which can prevent XSS?
which can provide proper handler message instead of 400 Bad Request in the
response.

BR,
Chethan

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/93657597-9cb9-4e87-b7cf-d97d2ba113bf%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

2

I'm not sure on the official stance for this sort of thing, but 0.19.X is
pretty old (nearly 18 months,
Elasticsearch Platform — Find real-time answers at scale | Elastic) and you'd be better off
upgrading than expecting a quick fix.

Maybe one of the devs can give some better insight though.

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: markw@campaignmonitor.com
web: www.campaignmonitor.com

On 16 December 2013 18:09, Chethan B D chethan.bd@enhancesys.com wrote:

Hi All,

Issue: Elasticsearch server (port:9200) is prone to the XSS
vulnerability.

*version: *0.19.8

Environment: RHEL 5.10

Vulnerability Description:
The Elasticsearch server fails to adequately sanitize request strings of
malicious JavaScript.
So, an attacker may be able to cause arbitrary HTML and script code to be
executed in a user's browser within the security context of the affected
site.

The request string used to detect this flaw was :
/scripts/uw12snbk.asp?

The output was :

HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Content-Type: text/plain; charset=UTF-8
Content-Length: 108

No handler found for this uri
[/scripts/uw12snbk.asp?] and method [GET]

So, Is there a Elastic Search server configuration which can prevent XSS?
which can provide proper handler message instead of 400 Bad Request in
the response.

BR,
Chethan

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/93657597-9cb9-4e87-b7cf-d97d2ba113bf%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624btDmGJ2ftC8-nVSQjZWSik5sj7aJyzH126fUXqWSo_8A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

3

400 Bad Request is a proper response in respect to
http://tools.ietf.org/search/rfc2616#section-10.4.1

Access-Control-Allow-Origin: * is to ease javascript development

And the code is not executed at
all, is it?

Can you describe the environment in which an exploit works?

Jörg

On Mon, Dec 16, 2013 at 8:09 AM, Chethan B D chethan.bd@enhancesys.comwrote:

Hi All,

Issue: Elasticsearch server (port:9200) is prone to the XSS
vulnerability.

*version: *0.19.8

Environment: RHEL 5.10

Vulnerability Description:
The Elasticsearch server fails to adequately sanitize request strings of
malicious JavaScript.
So, an attacker may be able to cause arbitrary HTML and script code to be
executed in a user's browser within the security context of the affected
site.

The request string used to detect this flaw was :
/scripts/uw12snbk.asp?

The output was :

HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Content-Type: text/plain; charset=UTF-8
Content-Length: 108

No handler found for this uri
[/scripts/uw12snbk.asp?] and method [GET]

So, Is there a Elastic Search server configuration which can prevent XSS?
which can provide proper handler message instead of 400 Bad Request in
the response.

BR,
Chethan

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/93657597-9cb9-4e87-b7cf-d97d2ba113bf%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHcvPscGB%2B92pdLg5aefkCBD3LrUn9BW3EswGgbWve%2B6w%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

4

Hi Jörg,

Thanks for reply.
We tested in RHEL 5.10

Please find below screenshot how its tested.
Here its response from server is *400 Bad response. *
For request: wget http://192.168.0.56:9200/anyPath

https://lh5.googleusercontent.com/-9pyO9aXdc5A/UrvrrgIXhYI/AAAAAAAAAGU/2KVQjzCQ30U/s1600/400.PNG

How can I respond with custom error message instead of 400 Bad Request in
the response*.*

BR,
Chethan

On Monday, December 16, 2013 7:06:06 PM UTC+5:30, Jörg Prante wrote:

400 Bad Request is a proper response in respect to
http://tools.ietf.org/search/rfc2616#section-10.4.1

Access-Control-Allow-Origin: * is to ease javascript development
Elasticsearch Platform — Find real-time answers at scale | Elastic

And the code is not executed at
all, is it?

Can you describe the environment in which an exploit works?

Jörg

On Mon, Dec 16, 2013 at 8:09 AM, Chethan B D <cheth...@enhancesys.com<javascript:>

wrote:

Hi All,

Issue: Elasticsearch server (port:9200) is prone to the XSS
vulnerability.

*version: *0.19.8

Environment: RHEL 5.10

Vulnerability Description:
The Elasticsearch server fails to adequately sanitize request strings of
malicious JavaScript.
So, an attacker may be able to cause arbitrary HTML and script code to be
executed in a user's browser within the security context of the affected
site.

The request string used to detect this flaw was :
/scripts/uw12snbk.asp?

The output was :

HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Content-Type: text/plain; charset=UTF-8
Content-Length: 108

No handler found for this uri
[/scripts/uw12snbk.asp?] and method [GET]

So, Is there a Elastic Search server configuration which can prevent XSS?
which can provide proper handler message instead of 400 Bad Request in
the response.

BR,
Chethan

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/93657597-9cb9-4e87-b7cf-d97d2ba113bf%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/6e12cd71-b9af-441d-be97-81d4bfeb861f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

5

As said, response "HTTP/1.1 400 Bad Request" is correct.

Note that Content-type is text/plain, so echoing the URI should be safe, it
means, the content is not executable.

If you want another response, here is the line that creates the response in
case no handler was found

https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestController.java#L166

I agree that it would be nicer to have ES REST return Content-Type
application/json only, and suppress the original URI in the response.

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoG6-HL18mjcAc-0DUooF3WRvWZbpyXSuEuGyMLuMaTnYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

6

Thanks a lot Jörg Prante..

On Sunday, December 29, 2013 1:14:33 AM UTC+5:30, Jörg Prante wrote:

As said, response "HTTP/1.1 400 Bad Request" is correct.

Note that Content-type is text/plain, so echoing the URI should be safe,
it means, the content is not executable.

If you want another response, here is the line that creates the response
in case no handler was found

https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestController.java#L166

I agree that it would be nicer to have ES REST return Content-Type
application/json only, and suppress the original URI in the response.

Jörg

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/50fab84c-896b-4d51-8513-dc9d6141802a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.