Is Unsecured OPTIONS Method A Vulnerability?

I've been working lately on a project utilizing ElasticSearch and Kibana.
To secure the ElasticSearch API I've hidden it behind a reverse proxy.

The proxy uses a cookie to authenticate the request and forward it to the
ElasticSearch server, but if no cookie is present or if the cookie does not
validate, then 401 is returned.

Here's the catch. Kibana uses CORS to communicate with ElasticSearch, so
while I can enable the Kibana HTTP client to use the withCredentials option
which will include cookies, it only does so for the four CRUD HTTP verbs.
Glaringly, any OPTIONS requests from Kibana will not include the cookie.

This makes sense on a certain level due to the description of the intended
purpose for the OPTIONS verb in the HTTP spec.

As such, in order to get my front-end functioning through this reverse
proxy I've had to white-list all OPTIONS requests. I'm concerned with
whether or not this could be abused to get commands through to the ES
server that I otherwise wouldn't want. I trust that Kibana is using the
verb properly, but if an attacker crafted an OPTIONS request at a server
with the request /_shutdown, would the ElasticServer know that since this
is an OPTIONS request it should ignore anything else in the request?

Admittedly I'm a bit in the dark about how the ES server receives and
handles commands over http beyond the typical RESTful functionality. Anyone
can shed some light?

--
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/3be24cfc-c247-4ab7-9733-e494f527529b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

A quick check shows that ES returns nothing with an options request via
curl.

ES uses netty to serve HTTP content.

On 12 February 2015 at 08:50, stv.bell07@gmail.com wrote:

I've been working lately on a project utilizing ElasticSearch and Kibana.
To secure the ElasticSearch API I've hidden it behind a reverse proxy.

The proxy uses a cookie to authenticate the request and forward it to the
ElasticSearch server, but if no cookie is present or if the cookie does not
validate, then 401 is returned.

Here's the catch. Kibana uses CORS to communicate with ElasticSearch, so
while I can enable the Kibana HTTP client to use the withCredentials option
which will include cookies, it only does so for the four CRUD HTTP verbs.
Glaringly, any OPTIONS requests from Kibana will not include the cookie.

This makes sense on a certain level due to the description of the intended
purpose for the OPTIONS verb in the HTTP spec.

As such, in order to get my front-end functioning through this reverse
proxy I've had to white-list all OPTIONS requests. I'm concerned with
whether or not this could be abused to get commands through to the ES
server that I otherwise wouldn't want. I trust that Kibana is using the
verb properly, but if an attacker crafted an OPTIONS request at a server
with the request /_shutdown, would the ElasticServer know that since this
is an OPTIONS request it should ignore anything else in the request?

Admittedly I'm a bit in the dark about how the ES server receives and
handles commands over http beyond the typical RESTful functionality. Anyone
can shed some light?

--
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/3be24cfc-c247-4ab7-9733-e494f527529b%40googlegroups.com
https://groups.google.com/d/msgid/elasticsearch/3be24cfc-c247-4ab7-9733-e494f527529b%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
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/CAEYi1X91QFbU%3DFXWXqOBS1rv7BH98YKBnnoWMB69sSgM_L0Rqg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.