[Galene] Re: CORS help needed

[Galene] Re: CORS help needed

[Marty Betz]

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On 2024-11-03, Juliusz Chroboczek wrote:
> Currently, Galene has a very primitive CORS configuration: either
> publicServer is not set in the config file, in which case no CORS headers
> are produced, or publicServer is set, in which case CORS headers allow
> unrestricted access

Because of required access to /public-group.json and /groups/groupname,
your bundled clients are only functional because they live on the same
domain as your server.

I guess one could argue that administrative requests should only be allowed
from a browser using these bundled example clients. Maybe all third party
client implementations should need to access "admin" APIs from a
site-generating server. (And thus, no CORS needed, and lessened XSS
vulnerability.)

So drawing a line between browser accessible API calls needing CORS, and
those you'd prefer to be accessible only from server would definitely be
useful.

I'm just learning about Galene details. What are administrative
interactions vs user interactions?

Questions:
1. For instance, will third party clients often want CORS access to data
like /public-groups.json?

2. Couldn't XSS allow for nefarious websocket listening and response? Does
the signaling protocol not also contain "administrative" possibilities?

Thank you,
Marty

[-- Attachment #2: Type: text/html, Size: 1410 bytes --]

[Galene] Re: CORS help needed

[Juliusz Chroboczek]

> I'm just learning about Galene details. What are administrative
> interactions vs user interactions?

Galene currently implements three independent protocols:

1. the native protocol, carried over a WebSocket over TLS;

2. the WHIP ingress protocol, carried over HTTP over TLS;

3. a REST-like interface for administration, used by the "change password"
   dialog and by the galenectl tool; hopefully, at some point somebody
   will write a graphical administration tool (but it won't be me).

> 1. For instance, will third party clients often want CORS access to data
> like /public-groups.json?

Yes, they'll want to be able to display the list of public groups.  They
might also want to allow a user to change their password.

-- Juliusz

[Galene] Re: CORS help needed

[Juliusz Chroboczek]

> Be careful of WebSockets, if I recall correctly they don't have CORS
> headers. However, some Golang libraries implicitly add an origin check on
> WebSocket connection.

We already handle that.  See lines 504 and 518 in webserver.go.

[Galene] Re: CORS help needed

[Alexandre IOOSS]

On 11/4/24 11:24, Juliusz Chroboczek wrote:
>> In such scenario, if an attacker manage to get XSS on the custom frontend
>> (for example through a badly implemented chat box), I clearly don't want
>> them to be able to request the administrative endpoint. So having separate
>> directives is a safer choice.
> 
> Okay, you've convinced me.  What's the right syntax?  A list of strings,
> the server finds the first origin that matches and dynamically generates
> a header for that specific origin?

Why not. According to 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin#directives 
there must be some server side code to find the matching origin.


Be careful of WebSockets, if I recall correctly they don't have CORS 
headers. However, some Golang libraries implicitly add an origin check 
on WebSocket connection. See 
<https://dev.to/pssingh21/websockets-bypassing-sop-cors-5ajm>.

Best,
-- Alexandre

[Galene] Re: CORS help needed

[Juliusz Chroboczek]

> In such scenario, if an attacker manage to get XSS on the custom frontend
> (for example through a badly implemented chat box), I clearly don't want
> them to be able to request the administrative endpoint. So having separate
> directives is a safer choice.

Okay, you've convinced me.  What's the right syntax?  A list of strings,
the server finds the first origin that matches and dynamically generates
a header for that specific origin?

-- Juliusz

[Galene] Re: CORS help needed

[Alexandre IOOSS]

Hello,

On 11/3/24 09:59, Juliusz Chroboczek wrote:
> 
>    - should we be allowing CORS on the administrative interface, or is it
>      a security risk?
> <snip>
> 
>    - shold it be a single boolean, as right now, or should the user be able
>      to specify a specific domain?
> 
> My current understanding is:
> 
>    - we should allow CORS, but make it default to no;
> 
>    - we should have two distinct directives;
> 
>    - we shold allow specifying a domain, or even a small number of domains.

My two cents on the subject: we shouldn't motivate to set 
'Access-Control-Allow-Origin: *' anywhere.
Users might set CORS to '*' to have a working setup, but might not 
realize that now example.com can request their Galène instance (even if 
Galène is hosted on a private network).

IMHO, a explicit configuration with a whitelist of allowed domain is a 
much better solution compared to a boolean.

>>    - should we have a single directive to control CORS, or should there be
>>      separate directives for audio/video and for administration?

Let's consider a previous setup I had with Galène in some student 
organization:
  - Domain A hosts a modified Galène frontend.
  - Domain B hosts a vanilla Galène server behind a NGINX reverse proxy.
  - Domain B uses some NGINX directives to manually add a CORS header to 
allow domain A to query Galène.

In such scenario, if an attacker manage to get XSS on the custom 
frontend (for example through a badly implemented chat box), I clearly 
don't want them to be able to request the administrative endpoint. So 
having separate directives is a safer choice.

Best,
-- 
Alexandre