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+unsubscr...@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.
