Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable CORS by default #7151

Closed
konklone opened this Issue Aug 4, 2014 · 5 comments

Comments

Projects
None yet
7 participants
@konklone
Copy link

commented Aug 4, 2014

Elasticsearch currently defaults CORS to being enabled for all domains.

cors-true

This is a security issue for any developer running Elasticsearch locally at localhost:9200 -- any website they visit can fire off arbitrary HTTP requests to their local machine. This should be disabled by default.

I became aware of this issue during the hubbub over the dynamic scripting vulnerability in 1.1's defaults (now changed in 1.2, and scripting sandboxed in 1.3). CORS magnified the effect of that bug for developers browsing the web, but even with dynamic scripting disabled, websites can still perform arbitrary Elasticsearch actions to a local instance of ES.

When I mention to developers that localhost:9200 is accessible via any website they visit, they are very surprised, as was I. Yes, maybe it's something I and everyone should have understood going in, but that's not happening. And while it may not be unique to Elasticsearch, this isn't a problem with most databases and database-like systems developers are used to running locally.

I've seen people recommend using Elasticsearch in a VM during development, but this is overhead caused by a choice Elasticsearch makes. Elasticsearch's current default CORS setting adds convenience for some, at the expense of security for many developers.

Any plugins or support systems that depend on enabling CORS for Elasticsearch can provide instruction to enable CORS (along with a warning of serious side effects) as part of their installation.

Elasticsearch should provide a safe experience by default. The dynamic scripting issue, which took some time to be seen as a security issue, is now CVE-2014-3120. Elasticsearch should get in front of this one.

@seanherron

This comment has been minimized.

Copy link

commented Aug 4, 2014

+1 - I know a lot of people running Elasticsearch locally on their machine with no knowledge of these risks, and there seems to be a common (incorrect, as @konklone mentions) belief that browsers restrict requests to localhost.

Sane defaults would most help people new to using Elasticsearch who are unaware of these risks. Enabling CORS is a simple step for people to take if they need that functionality.

@kimchy

This comment has been minimized.

Copy link
Member

commented Aug 4, 2014

Agreed fully!, it seems like we can preserve the good out of the box experience with matching only localhost origin out of the box, we worked on this to add it: #6923, where the next step is to change the default. We haven't done it yet, the aim is to do it for 1.4 (I will label this issue as well as such). Does that sound reasonable?

@kimchy kimchy added v1.4.0 labels Aug 4, 2014

@konklone

This comment has been minimized.

Copy link
Author

commented Aug 4, 2014

This sounds very reasonable, and thank you for taking it seriously!

@rashidkpc

This comment has been minimized.

Copy link
Member

commented Aug 22, 2014

After some thought I'm not sure there's a strong reason to use a regex to match localhost by default. When an application developer eventually goes to production they'll need to learn about the CORS setting anyway, might as well do it early.

Regex matching is definitely an important feature, but we should probably just turn off CORS (set to null) by default, for the sake of configuration readability.

@bleskes

This comment has been minimized.

Copy link
Member

commented Aug 25, 2014

+1 on implementing regex support, documenting an example for allowing localhost access an disabling it by default. The use case we want to support is plugins and CORS is not relevant for that (as they are hosted by ES). Plugin developers on the other hand need to know about this early as it may impact the choice of deployment (as @rashidkpc said)

@clintongormley clintongormley assigned spinscale and unassigned kimchy Sep 8, 2014

spinscale added a commit to spinscale/elasticsearch that referenced this issue Sep 9, 2014

CORS: Disable by default
In order to deliver a more secure out-of-the-box configuration this commit
disables cross-origin resource sharing by default.

Closes elastic#7151

spinscale added a commit that referenced this issue Sep 9, 2014

CORS: Disable by default
In order to deliver a more secure out-of-the-box configuration this commit
disables cross-origin resource sharing by default.

Closes #7151

asquelt added a commit to linuxpolska/cloudbliss that referenced this issue Jun 23, 2015

elastic 1.4 requires CORS settings to be explicitly enabled
setting it to reflect origin header, don't use this scheme on production.

elastic/elasticsearch#7151
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.