Blocking Cross Origin WebSocket Attempt - behind load balancer about jupyter_server HOT 4 OPEN

Gotta be careful when X-Forwarded-Host unconditionally. See rails/rails#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

from jupyter_server.

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

from jupyter_server.

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.

from jupyter_server.

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.

from jupyter_server.