[Galene] CORS help needed

[Galene] CORS help needed

[Juliusz Chroboczek]

Hello,

The administrative interface currently doesn't provide any CORS headers.
This means tha people cannot access it from third-party web sites, they
need to either integrate their code into Galene or use native clients.

This is https://github.com/jech/galene/issues/226

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 (and the
equivalent for the WebSocket protocol) allow unrestricted access to both
the native protocol and the WHIP ingress protocol.

In either case, the administrative interface is not affected.

Questions to the experts:

  - should we be allowing CORS on the administrative interface, or is it
    a security risk?
  
  - should we have a single directive to control CORS, or should there be
    separate directives for audio/video and for administration?

  - 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.

Thanks for your help,

-- 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

[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]

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]

> 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.