Change the application access authentication flow

[ryanclark]

Previously, we'd pass the value of the cookie that needed to be set to /x-teleport-auth via the POST body. This opened it up to CSRF attacks, which was mediated by implementing a ?state= query param and a cookie.

This added quite a few different redirects, which can be simplified by allowing cross origin requests from the proxy address to the application's /x-teleport-auth endpoint, and sending the cookie value via a custom X-Cookie-Value header instead.

Custom headers cannot be added to <form> elements, nor included in a no-cors fetch() request. This means a user cannot be tricked into launching an application by a third party malicious actor.

This would fix #15935, as we're no longer relying on the cookie that gets unset by the x-teleport-auth dance.

[ikkisoft]

In term of security and protection against Login CSRF, the current implementation is comparable to the previous one. I did leave one comment, since I believe this mechanism will break for teleport installations that are configured with multiple public IPs/Domain names.

However, it's important to note that this security mechanism fully relies on a properly configured CORS policy. Given that the Access-Control-Allow-Origin uses the teleport's configuration (public_addr field), it is particularly important to ensure that all hostnames listed in this setting are trusted. Arbitrary HTML/Javascript hosted under such domains will have full access to cross-origin requests hence bypassing this protection.

[ryanclark]

In term of security and protection against Login CSRF, the current implementation is comparable to the previous one. I did leave one comment, since I believe this mechanism will break for teleport installations that are configured with multiple public IPs/Domain names.

However, it's important to note that this security mechanism fully relies on a properly configured CORS policy. Given that the Access-Control-Allow-Origin uses the teleport's configuration (public_addr field), it is particularly important to ensure that all hostnames listed in this setting are trusted. Arbitrary HTML/Javascript hosted under such domains will have full access to cross-origin requests hence bypassing this protection.

Arbitrary HTML/JS on any proxy address is an issue in general, as it'll give access to the proxy API without CORS being needed.

I don't see this being an issue, there would be more attack vectors if there was arbitrary HTML/JS on a proxy endpoint than a POST /x-teleport-auth setting a cookie value (that doesn't guarantee app access, as the cookie value needs to be known).

That being said, I wouldn't be against a HMAC signature for the cookie that's also passed along, so brute force attempts to guess a cookie value couldn't be achieved.

Thanks for taking the time to review this.

[ikkisoft]

Agree. I was mostly concerned about a user's misconfiguration in which the CORS Access-Control-Allow-Origin returns an host that is not owned by the admin. E.g. dangling DNS records

[r0mant]

@ryanclark I tried this branch in my local cluster and I can't connect to any applications. I get "Access to XXX was denied" from the browser.

Changes addressed