Open Redirect in Aspnet with Basic Auth

An open redirect in an ASP.NET application using HTTP Basic Authentication can arise when a redirect target is derived from user-controlled input and the same authentication credentials are sent to the redirect destination. In this scenario, the client first authenticates with Basic Auth (a username and password encoded in the Authorization header), and the server then uses a parameter such as returnUrl to redirect the client after login or logout. If the server does not strictly validate or whitelist the destination, an attacker can supply a malicious external URL as returnUrl. Because the client’s browser retains the Authorization header for the original host, some browsers may inadvertently include credentials when following the redirect to the attacker’s domain, or the application logic may treat the redirect as trusted, leading to credential exposure or phishing.

For example, consider a login flow where the client authenticates with Basic Auth and the server performs a redirect based on a query string without validation:

// Example of vulnerable behavior in ASP.NET Core
app.Use(async (context, next) =>
{
    var returnUrl = context.Request.Query["returnUrl"];
    if (!string.IsNullOrEmpty(returnUrl))
    {
        context.Response.Redirect(returnUrl);
        return;
    }
    await next();
});

An attacker could craft a URL like https://api.example.com/login?returnUrl=https://evil.com. After the server redirects, the client’s browser navigates to the attacker’s site. Even though the redirect itself does not leak the Basic Auth credentials in the URL, the combination of prior authentication and an unchecked redirect can facilitate phishing or token/session fixation scenarios depending on how cookies and headers are handled across domains.

Another angle involves misconfigured CORS or referer headers. If the application makes authenticated requests to the redirect target and the target is external, the browser may send the Basic Auth credentials to the external host if the redirect causes a cross-origin request that includes credentials (e.g., via fetch with credentials: 'include'). This can occur when the client-side logic follows the redirect programmatically rather than relying on a simple server redirect. Such patterns increase the risk of unintended credential disclosure to third parties.

In the context of middleBrick’s checks, an unauthenticated scan may flag an open redirect when a redirect parameter is not properly constrained, and a separate check for unsafe consumption may highlight places where credentials could be leaked via cross-origin requests. These findings are reported with severity and remediation guidance to help you address the issue before it can be weaponized.

To mitigate open redirect risks in ASP.NET while using Basic Auth, validate and restrict redirect destinations, avoid using raw user input for navigation, and ensure credentials are not unnecessarily propagated to external hosts.

1) Use an allowlist for redirect targets. Only permit redirects to known, relative paths or a strict set of trusted origins. Do not rely on hostnames or protocols provided by the client.

// Secure redirect with an allowlist in ASP.NET Core
var allowedHosts = new HashSet(StringComparer.OrdinalIgnoreCase)
{
    "app.example.com",
    "trusted.example.com"
};

app.Use(async (context, next) =>
{
    var returnUrl = context.Request.Query["returnUrl"];
    if (!string.IsNullOrEmpty(returnUrl))
    {
        var uri = Uri.TryCreate(returnUrl, UriKind.Absolute, out var parsed) ? parsed : null;
        if (uri != null && allowedHosts.Contains(uri.Host))
        {
            context.Response.Redirect(uri.ToString());
            return;
        }
        // Fallback to a default safe location
        context.Response.Redirect("/");
        return;
    }
    await next();
});

2) Prefer relative redirects. When possible, redirect using relative paths instead of absolute URLs constructed from user input.

// Relative redirect example
if (Uri.TryCreate(returnUrl, UriKind.Relative, out var relative))
{
    context.Response.Redirect(relative.ToString());
}

3) Avoid including credentials in cross-origin requests. Do not configure HTTP clients or browser fetch calls to include credentials when calling external URLs derived from user input. If you must follow a redirect programmatically, validate the destination strictly and do not forward the Authorization header to external domains.

// Example of safe HttpClient usage without forwarding Basic Auth
var handler = new HttpClientHandler();
// Do not set UseDefaultCredentials or automatically attach authentication headers to external requests
var client = new HttpClient(handler);
// Validate before any request
string destination = GetValidatedDestination(userInput);
var response = await client.GetAsync(destination);

4) Use ASP.NET Core anti-forgery and policy-based authorization. Combine anti-forgery tokens for state-changing operations with a strict policy for allowed redirect targets. This reduces reliance on potentially tampered query parameters.

// Example using a policy to validate origins
services.AddAuthorization(options =>
{
    options.AddPolicy("SafeRedirect", policy =>
        policy.RequireAssertion(context =>
        {
            var httpContext = context.Resource as HttpContext;
            var returnUrl = httpContext?.Request.Query["returnUrl"];
            if (string.IsNullOrEmpty(returnUrl)) return true;
            var uri = Uri.TryCreate(returnUrl, UriKind.Absolute, out var parsed) ? parsed : null;
            return uri != null && allowedHosts.Contains(uri.Host);
        }));
});

By applying these patterns, you reduce the likelihood that an open redirect can be leveraged to steal credentials or conduct phishing, even when Basic Auth is in use. Regular scans with tools like middleBrick can help identify remaining open redirect vectors and other risky patterns in your API endpoints.