# Is Unsecured OPTIONS Method A Vulnerability? **URL:** \ **Category:** Elasticsearch\ **Created:** [February 11, 2015, 9:50pm UTC](https://discuss.elastic.co/t/is-unsecured-options-method-a-vulnerability/22117 "2015-02-11T21:50:20Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![stv\_bell07](https://avatars.discourse-cdn.com/v4/letter/s/8dc957/32.png) [@stv\_bell07](https://discuss.elastic.co/u/stv_bell07)\ **Post date:** [February 11, 2015, 9:50pm UTC](https://discuss.elastic.co/t/is-unsecured-options-method-a-vulnerability/22117/1 "2015-02-11T21:50:20Z")
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](mailto: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). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![warkolm](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/warkolm/32/39224_2.png) [@warkolm](https://discuss.elastic.co/u/warkolm)\ **Post date:** [February 13, 2015, 1:27am UTC](https://discuss.elastic.co/t/is-unsecured-options-method-a-vulnerability/22117/2 "2015-02-13T01:27:56Z")
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](mailto: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](mailto: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) > [https://groups.google.com/d/msgid/elasticsearch/3be24cfc-c247-4ab7-9733-e494f527529b%40googlegroups.com?utm\_medium=email&utm\_source=footer](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](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](mailto: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](https://groups.google.com/d/msgid/elasticsearch/CAEYi1X91QFbU%3DFXWXqOBS1rv7BH98YKBnnoWMB69sSgM_L0Rqg%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:33am UTC](https://discuss.elastic.co/t/is-unsecured-options-method-a-vulnerability/22117/3 "2017-07-06T00:33:04Z")