Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Changes in CORS configuration for Eclipse Che.

I can propose such an alternative.

1. 6.15 we introduce the ability to disable auth on CORS. Auth will be enabled by default like in 6.14. Tomcat 8.5.23 
2. 6.16 auth will be disabled by default. Tomcat 8.5.x - latest.
3. 6.17 We remove CORS from the master if we have no complaints from stage 1 and 2.

Will, it works for you?

On Fri, Nov 23, 2018 at 1:29 PM Ilya Buziuk <ibuziuk@xxxxxxxxxx> wrote:
There is a possibility that che.openshift.io will be affected by this changes due to things like e2e flow.
Sergii, would it be possible to disable CORS on workspace master via some property initially before completely removing CORS support?
This would probably be a good way to deprecate the functionality, which would give some time to community to make relevant changes if CORS on wsmaster is somehow used in the downstream projects.

On Fri, Nov 23, 2018 at 10:01 AM Gennady Azarenkov <gazarenk@xxxxxxxxxx> wrote:


On Fri, Nov 23, 2018 at 10:29 AM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:


On Fri, Nov 23, 2018 at 10:20 AM Florent Benoit <florent@xxxxxxxxxx> wrote:
Sergii, can we know for example on che.openshift.io how many requests are done with CORS ?
also maybe it's a good topic to raise at che dev meeting ?
Yes sure, a collection of feedback was the main intention of this mail thread. 

Yes, sure, but how we see the role of dev meeting for this case?

Is it just to be able to discuss it one more time, live
OR
Make an end decision (how if so)

Thoughts?


Florent

On Fri, Nov 23, 2018 at 8:56 AM Gennady Azarenkov <gazarenk@xxxxxxxxxx> wrote:
+1

The feature looks quite marginal to support (compromised) CORS on master for it.

On Fri, Nov 23, 2018 at 9:49 AM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
Since there is not much activity here.

My plan.
1. Upgrade Tomcat with the latest version + removing CORS at all from the master.
2. Initiate "deprecate and remove" procedure of "export to the private cloud" feature.

If anyone has any concerns or comments please let me know here in email or on next Che call that suppose to happen next Monday.
I'm going to execute described plan starting from next Tuesday, Nov 27.

On Tue, Nov 20, 2018 at 1:36 PM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:

Hello Florent.
On Mon, Nov 19, 2018 at 12:31 PM Florent Benoit <florent@xxxxxxxxxx> wrote:
Hello Sergii,

> There is no functionality in upstream that uses CORS on workspace master and CORS on workspace agent are used only for IDE. 

Hello, I don't know how you checked functionalities, but AFAIK the export to private cloud feature of dashboard is using CORS (as it needs to connect to another remote workspace master endpoint)

Yes. You are right. There is such functionality. We missed it because there is no integration test for it.
Another sad thing is that this functionality last time worked with Che5 + Codenvy. Because it uses 
authentification methods that are no longer exist in Che6/7 era.

What we can do:

With CORS filter on workspace master.

1. Do not upgrade tomcat with the latest security fixes.  Does anybody think that this is a good idea?
2. Allow configuring "origins" from the configuration. Quite useless since we don't know all the possible locations.
3. Disable auth on CORS. Limits functionality to public methods only.
4. Remove CORS at all from the master. In this way, we remove potential CORS vulnerabilities on ws-master from the agenda.

My preference: 4 or 3.

With "export to private cloud" - functionality.

1. Just create a bug about not working functionality and forget.
2. Deprecate and remove. We have alternatives: Export as a file. copy/paster json. devfile is coming https://github.com/eclipse/che/issues/11549
3. Fix this functionality in the combination of some sort of OAuth + server-side service method to be able safely sent authorization data.

I think 3 can quickly look like as 1. That is why I think 2 is the best way.

Thoughts?
 
image.png

Also maybe there is other stuff using CORS from dashboard
 
The dashboard is not an issue if we talking about the same host.
With ws-master, they are on the same domain. With agent: we are going to allow the request from dashboard's host.
 

Florent

On Sat, Nov 17, 2018 at 3:56 PM Sergii Kabashniuk <skabashn@xxxxxxxxxx> wrote:
Hello
Recently we decided to review our CORS configuration to make sure that it's satisfying modern security requirements. 

There is no functionality in upstream that uses CORS on workspace master
and CORS on workspace agent are used only for IDE. 

To make Che more secure, we want to remove CORS filter from the workspace master at all.
On ws-agent side, we want to limit Allow-Origin to the host from which IDE was loaded.

If you see any problems with that please let me know.
Useful links


Some similar security issues:

Some related blog posts:

--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    



--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    



--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev


--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    



--

ILYA BUZIUK

SENIOR SOFTWARE ENGINEER

Red Hat 

ibuziuk@xxxxxxxxxx   



--

Sergii Kabashniuk

Principal Software Engineer, DevTools 

Red Hat Ukraine

skabashniuk@xxxxxxxxxx    


Back to the top