Don't send credentials when redirected to the pool #254
Comments
|
This looks like a problem with the Fetch API, but one that has been reported (see whatwg/fetch#944). Right now, there seems to be no way to prevent the browser from sending credentials to the pool if the WebDAV door responds with a redirect. |
paulmillar
added a commit
to dCache/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
paulmillar
added a commit
to paulmillar/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
This was referenced May 11, 2021
mksahakyan
pushed a commit
to dCache/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
mksahakyan
pushed a commit
to dCache/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
mksahakyan
pushed a commit
to dCache/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
mksahakyan
pushed a commit
to dCache/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
mksahakyan
pushed a commit
to dCache/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
mksahakyan
pushed a commit
to dCache/dcache
that referenced
this issue
May 11, 2021
Motivation: If dCacheView makes a GET request against the WebDAV for which it supplies credentials and the door redirects dCacheView to a pool then dCacheView will use the same credentials when making the GET request to the pool. This bug is recorded as dCache/dcache-view#254. Currently, the pool responds to the CORS preflight request indicating that the client must not send credentials. When faced with this conflict, the web-browser fails the GET request. It looks like it's currently impossible to prevent the web-browser from resending the WebDAV-credentials to the pool (see whatwg/fetch#944). Therefore, to support dCacheView, the pool must allow client credentials, which (in turn) is only safe for TLS-protected transfers. Modification: Update pool's CORS configuration to allow the client to send a credential for https transfers. The pool continues to ban sending credentials for http (i.e., unencrypted) transfers. Result: dCacheView now works for redirected transfers for non-anonymous data access, provided the WebDAV door is using TLS encryption and is configured with 'webdav.redirect.allow-https' set to 'true'. This, in turn, requires the pool has TLS enabled and presents an X.509 certificate from a CA that the browser trust. Target: master Requires-notes: yes Requires-book: no Request: 7.1 Request: 7.0 Request: 6.2 Request: 6.1 Request: 6.0 Request: 5.2 Patch: https://rb.dcache.org/r/13018/ Acked-by: Tigran Mkrtchyan Acked-by: Lea Morschel
|
The upstream bug (whatwg/fetch#944) is now closed by updating the live document. Insecure headers (including Note that the different implementations (browsers) may lag in implementing this update. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Transfers (uploads or downloads) are done using a WebDAV door. This is a GET or PUT request. For username+password, OIDC or Macaroon-based authentication, the GET or PUT request will include an
AuthorizationHTTP header that contains the credential.The door may (perhaps "should") redirect the client to the pool so that the transfer is not relayed through the door. When the door does this, the redirection URL contains a single-use token that authorises the transfer.
Currently, when dCacheView is redirected to the pool, it will include the credential in the request.
Beyond simply being redundant, this is bad as the WebDAV door may redirect the client to an unencrypted connection when connecting to the pool.
The text was updated successfully, but these errors were encountered: