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?
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?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.