Document secure deployment and security measures

[mgjm]

I would like to document what parts of securing theia are handled by theia and what is the responsibility for application developers.

Current situation

From what I have read in other issues there are three possibilities to provide authentication credentials: Via the Authorization header (e.g. Basic auth), via cookies or via custom headers / parameters.

• Custom headers / parameters would require modifications to theia (out of scope for theia)
• Authorization headers are not sent for WebSockets by Safari (desktop and mobile)
• Cookies remain as the only way (as of now)

Both cookies and Basic auth are used in practice. Both share the property to be send by the browser automatically on every request to the domain. (Some people disable authentication for WebSockets).

Use Case

I would like to look at the following use case for the questions below:
A theia based application configured with the official extensions (e.g. from the documentation) and arbitrary theia / vscode plugins.
This theia based application should be deployed to the web and is therefore publicly reachable.

Security measures

• HTTPS (the application developer is responsible)
• Authentication (out of scope for theia, the application developer is responsible)
• CORS headers
• CSRF protection
• Content Security Policy

Questions

• Which of the above security measures are implemented by theia?
• Are all official extensions aware of these security measures and modify them if needed?
• Do plugins need to be aware of these or is this abstracted away by the plugin API?
• Is there something missing in the above list of security measures?
• Is it secure to disable authentication for WebSockets?
  • If so, is there some kind of internal authentication already in place
  • Or is this just an security hole needed to work with Authorization headers in Safari

Actions

I think it is important do document who is responsible for what in respect to these security measures.
Otherwise it is unclear for an application developer using theia, what needs to be done and what is already present.
This is especially important as a failure to protect theia properly can result in unrestricted command line access to the underlaying server / container. The most important aspect IMHO is proper CSRF protection as otherwise the cookies / authorization header could be used to access theia and issue arbitrary command from other domains.

• I would like to establish a policy on what security measures are implemented by theia. So that future changes to theia can keep these measures in mind and PRs can be checked against them. (Documented in this repo)
• I would like to document the abstract steps required to secure theia via an authentication proxy (in eclipse-theia/theia-website). This should also include the list of security measures provided by theia.

[paul-marechal]

• CORS headers

The backend doesn't send any Access-Control-Allow-Origin so it should put us in the case where COR are blocked IIUC.

• CSRF protection

You can configure a given Theia backend application to check the Origin header for specific domains: https://github.com/eclipse-theia/theia/blob/master/packages/core/README.md#environment-variables. Note that it only affects WebSocket connections for now. This is the most sensitive place of Theia since all of our APIs go through WebSockets.

I think some form of CSP is used when dealing with plugins and webviews.

I don't know enough about the rest to answer.

[mgjm]

@marechal-p Thanks for the first response. Do you know who can be tagged that would know more about the rest?