don't distinguish private ips in xsrf tokens #4991
Conversation
almost certainly proxy ips, which don't solve the problem anyway, and can change due to replicas
|
Does this potentially open up a vulnerability with CGNAT? |
…ID_HEADERS for influencing how anonymous xsrf tokens are computed including fully opting out of distinguishable xsrf ids for anonymous (login) requests
|
I believe |
|
I added a couple of environment variables $JUPYTERHUB_XSRF_ANONYMOUS_USE_IP and $JUPYTERHUB_XSRF_ANONYMOUS_ID_HEADERS to influence how the anonymous id is computed. I did this because it's influencing a top-level utility function and traitlets-style config will be a bit of a pain to get a Configurable instance properly loaded. But not impossible, if folks think standard config would be better here. The unique anonymous id can be fully disabled with: JUPYTERHUB_XSRF_ANONYMOUS_USE_IP=0
JUPYTERHUB_XSRF_ANONYMOUS_ID_HEADERS=in which case an xsrf cookie for one client is valid for all clients (assuming client is not authenticated), which opens a path to cookie tossing. |
| @@ -230,6 +234,17 @@ def check_xsrf_cookie(handler): | |||
| ) | |||
|
|
|||
|
|
|||
| # allow disabling using ip in anonymous id | |||
| _anonymous_use_ip = _bool_env("JUPYTERHUB_XSRF_ANONYMOUS_USE_IP", default=True) | |||
There was a problem hiding this comment.
Shouldn't we use JUPYTERHUB_XSRF_ANONYMOUS_USE_IP with False by default to avoid any security problem and keep the old behaviour?
I think this problem is more likely to occur in k8s deployment, so we can set this property to True on the chart side.
There was a problem hiding this comment.
I don't think so. True means keeping the current behavior by default, where the ip is used, which is correct most of the time (including in most z2jh deployments). Only where proxy headers don't properly propagate does this problem come up.
almost certainly proxy ips, which don't solve the problem anyway, and can change due to multiple proxy replicas
maybe closes jupyterhub/zero-to-jupyterhub-k8s#3422 for most users. A case where it wouldn't is a proxy outside the cluster/LAN, where the proxy's own ip is a global ip. For that, we'd need a more full opt-out of using ips.