Cookie authentication redirects with the base domain

[SirMrDexter]

Describe the bug

When using cookie authentication, the redirect URLs use the full URL instead of relative URLs. This causes issues with services which are managed behind load balancers. Although it can fixed with URL rewrite rules, it may not be ideal solution.

To Reproduce

1. Create a new web app and setup authentication services as below

services.AddAuthentication("MyAppAuth")
                .AddCookie("MyAppAuth", cookieAuthenticationOptions =>
                {
                    cookieAuthenticationOptions.AccessDeniedPath = new PathString("/Error/NoAccess/");
                    cookieAuthenticationOptions.LoginPath = new PathString("/Home/Login/");
                });

2. Add authentication middleware

applicationBuilder.UseAuthentication();

3. Setup a controller action with AuthorizeAttribute
4. Debug the project and go to the URL with AuthorizeAttribute

Expected Result:
Application returns a 302 response with the location header set to '/Home/Login/?returnUrl=....'

Actual Result:
Application returns a 302 response with the location header set to 'https://myapplicationdomain.com/Home/Login/?returnUrl=....'

Further technical details

Traced the changes back to this commit.
78cf7f9#diff-4e1d744cdbfdc6fa13724d45717a666bL72

Looks like it was done that way so it works for OAuth, which do need the full URL to make it work. But this causes issue with apps that do internal redirection and sit behind WAF and Load balancer services like Azure Application Gateway. Should be able to make the method virtual and override the behavior in CookieAuthenticationHandler, so it can use relative paths instead of full URL.

[Tratcher]

See https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-3.1 for our guidance on working with proxies and load balancers.

[blowdart]

What issues are you seeing with application gateway or load balances that you believe can be solved with relative paths?

[SirMrDexter]

Our application is hosted as azure web app behind an Application Gateway. Our public domain (say www.myapplication.com )is pointing to the AppGateway, which forwards the requests to the web app in backend pool. None of the apps in the backend pool are configured for the above mentioned domain. They all use the azurewebsites.net domain for communication between AppGateway and the backend app (something like my-backend-app.azurewebsites.net).

When we have a request from an unauthenticated user to a secure resource, the Cookie Authentication handler, responds with a 302 redirect. The location header is the response is to https://my-backend-app.azurewebsites.net/home/login?returnUrl=..... The backend app is network restricted and we don't want our clients to see it directly.

If the 302 response from Cookie Authentication handler had location set to relative URL like /home/login?returnUrl=.... instead of the full URL then the client will be redirected to https://www.myapplication.com/home/login?returnUrl=.... which is the correct location they need to go to.

Based on the documentation and the current framework code, at the moment there's no flag to change that behaviour. Also since the BuildRedirectUri method is not virtual, it makes creating any custom override class a pain.

The alternative way I was able to make it work is by modifying the CookieAuthenticationEvents like below.

    public class CustomCookieAuthenticationEvents : CookieAuthenticationEvents
    {
        public CustomCookieAuthenticationEvents()
        {
            var baseOnRedirectToAccessDenied = OnRedirectToAccessDenied;
            var baseOnRedirectToLogin = OnRedirectToLogin;
            OnRedirectToAccessDenied = (context) =>
            {
                MakeRedirectUriRelative(context);
                return baseOnRedirectToAccessDenied(context);
            };
            OnRedirectToLogin = (context) =>
            {
                MakeRedirectUriRelative(context);
                return baseOnRedirectToLogin(context);
            };
        }

        private void MakeRedirectUriRelative(RedirectContext<CookieAuthenticationOptions> context)
        {
            // If the redirectUri starts with the scheme, then remove the scheme and host from it,
            // as we are only after relative redirects for cookie authentications.
            if (context.RedirectUri.StartsWith(context.Request.Scheme))
            {
                // Remove scheme and host from redirectUri
                context.RedirectUri = context.RedirectUri.Substring(context.Request.Scheme.Length
                                                                    + context.Request.Host.ToString().Length + 3);
            }
        }
    }

I believe it's safe to override this behaviour just for the CookieAuthenticationHandler without impacting other authentication handlers.

[Tratcher]

The guideance for this scenario (see linked above) is to modify the Host field on the request rather than trying to customize every component that generates a link or redirect.

[blowdart]

As Chris says this is exactly what X-Forwarded-For and the other standard headers are designed for.

[SirMrDexter]

I read the docs and tested with the suggested sample code in there. Had to make some more changes to make it work though. Azure Application Gateway doesn't seem to use X-Forwarded-Host for the original domain name. Instead it use X-Original-Host. But X-Original-Host header seems to used for a different purpose in the ForwardedHeadersMiddleware.

Also I needed to clear both KnownNetworks and KnownProxies to make it work. Here the setup I had to do.

services.Configure<ForwardedHeadersOptions>(options =>
{
	options.ForwardedHeaders = ForwardedHeaders.All;
	options.ForwardedHostHeaderName = "X-ORIGINAL-HOST";
	options.OriginalHostHeaderName = "X-ORIGINAL-ORIGINAL-HOST";
	options.KnownNetworks.Clear();
	options.KnownProxies.Clear();
});

But even with that setup, I can't get the Remote IP to work. The remote IP still points to the IP of the Application Gateway instead of actual client IP from the X-Forwarded-For header.

Also is there any security implications when using this option. Given that its just a HTTP header, anyone could forge a header and pass it on as the original host, isn't it? How am I suppose to manage that?

[Tratcher]

There's a troubleshooting section in the doc that shows how to capture the headers coming from the proxy to make sure everything is set up right. Can you share that output?

Also is there any security implications when using this option. Given that its just a HTTP header, anyone could forge a header and pass it on as the original host, isn't it? How am I suppose to manage that?

Yes, but the gateway should be overwriting the header to prevent that kind of issue. Can your app also be accessed without going through the gateway?

[blowdart]

Also is there any security implications when using this option. Given that its just a HTTP header, anyone could forge a header and pass it on as the original host, isn't it? How am I suppose to manage that?

This really becomes questions for Azure Application gateway (along with why they use a different header name to everything else grin). You shouldn't manage it, a proxy should either be stripping them, or validating them.