Blocking Cross Origin WebSocket Attempt - behind load balancer

[timkpaine]

When running behind a load balancer/proxy, I get this error: Blocking Cross Origin WebSocket Attempt because the Host header doesn't match the Origin header (from here). However, this is supposed to be the case, as the "real" host will be in Forwarded or X-Forwarded-Host.

Would it make sense to check if these are set, and if so, to prefer them to the Host header when comparing to Origin?

[afshin]

What you suggest sounds like the correct behavior. It's not part of the standard, but it's a "de facto standard"

[yuvipanda]

Gotta be careful when X-Forwarded-Host unconditionally. See https://github.com/rails/rails/issues/29893 for an example of unforeseen security issues. A bunch of other web frameworks have features that list you explicitly set which IPs to trust X-Forwarded-Host headers from - https://expressjs.com/en/guide/behind-proxies.html.

This might not be a problem here for CORS, but something to carefully consider regardless

[rolweber]

Would it make sense to check if these are set, and if so, to prefer them to the Host header when comparing to Origin?

Definitely not. Any attacker can set headers as they wish, so it's a bad idea to disable security checks based on the fact that some header is present. Explicitly telling Jupyter through the configuration that it is running behind a load balancer, as suggested by @yuvipanda, sounds like the way to go.

[rolweber]

Maybe add logic around this line to use the value from a configured header (Forwarded or X-Forwarded-Host or whatever) in favor of the value from the Host header. The latter should still be used as a fallback in the absence of the configured header, in case somebody is hitting the same server directly instead of through the load balancer.

On second thought, it might still be possible to abuse this by hitting the server directly. Tricky thing.