Open Redirect Chain in Aspnet
How Open Redirect Chain Manifests in Aspnet
An Open Redirect Chain occurs when an attacker crafts a sequence of redirect URLs that bypass validation checks by exploiting how an application processes redirect parameters across multiple endpoints. In ASP.NET applications, this often stems from improper handling of return URLs in authentication flows or redirect helpers that fail to validate the final destination after a series of hops.
Common vulnerable patterns in ASP.NET include:
- Using
Redirect(returnUrl)in controllers wherereturnUrlis taken directly from query strings or form data without validation against a whitelist of allowed hosts. - Reliance on
Url.IsLocalUrl()that can be bypassed via techniques like//evil.com/path(scheme-relative URLs) or\\evil.com\path(UNC paths) in certain .NET Framework versions. - Chaining through open redirectors: Application A redirects to Application B using a user-controlled parameter, and Application B then redirects again based on another parameter, creating a chain that evades single-hop validation.
For example, an ASP.NET Core MVC controller might have:
public IActionResult Login(string returnUrl)
{
// Vulnerable: no validation of returnUrl
return Redirect(returnUrl);
}
An attacker could send a victim a link like: https://yourapp.com/Login?returnUrl=https://evil.com. If the application later chains this redirect—say, to a payment portal that also uses a return URL—the attacker might construct https://yourapp.com/Login?returnUrl=https://payment.yourapp.com/process?returnUrl=https://evil.com. If neither application validates the final destination, the victim ends up on the attacker’s site after what appears to be a trusted multi-step flow.
This is particularly dangerous in ASP.NET applications using Identity or OIDC middleware where RedirectUri parameters are passed through multiple services. Attackers have used similar chains in real-world exploits (cf. CVE-2020-0609 in SharePoint, though not ASP.NET-specific, the pattern translates) to steal tokens or session data by exploiting trust relationships between subdomains or services.
Aspnet-Specific Detection
Detecting Open Redirect Chains in ASP.NET requires analyzing both the application’s redirect logic and the actual HTTP responses from endpoints that accept user-controlled redirect parameters. middleBrick identifies this issue through its black-box scanning engine by:
- Injecting sequences of redirect payloads (e.g.,
//evil.com,\\evil.com,https://evil.com@trusted.com) into parameters commonly used for return URLs (returnUrl,redirect_uri,continue). - Tracking HTTP response codes and
Location headers across multiple requests to detect chains where an initial redirect leads to another redirect based on user input. - Correlating findings with ASP.NET-specific fingerprints (e.g.,
X-AspNetMvc-Version,ASP.NET_SessionIdcookies,__RequestVerificationTokenfields) to reduce false positives.
For instance, if scanning https://shop.example.com/login?returnUrl= with a payload like //attacker.com yields a 302 redirect to //attacker.com, middleBrick flags it as a potential open redirect. It then follows that redirect and tests whether https://attacker.com itself accepts and acts on a returnUrl parameter—indicating a chain.
middleBrick’s OWASP API Top 10 mapping places this under API1:2023 Broken Object Level Authorization (when redirect logic fails to enforce user intent) and API5:2023 Broken Function Level Authorization (if redirect endpoints are unintentionally exposed). The scanner also checks for bypasses of Url.IsLocalUrl() using known .NET framework-specific evasion techniques, such as those documented in Microsoft’s own guidance on URL validation.
Importantly, middleBrick does not require access to source code, configuration, or credentials. It tests the unauthenticated attack surface by submitting a URL and analyzing live responses, making it suitable for scanning staging or production ASP.NET APIs without disruption.
Aspnet-Specific Remediation
Fixing Open Redirect Chains in ASP.NET applications involves validating redirect URLs at every point where user input influences a redirect destination, using the framework’s built-in helpers correctly, and avoiding open redirectors in multi-step flows.
Key remediation steps:
- Always validate redirect URLs using
Url.IsLocalUrl()in ASP.NET Core orUrl.IsLocalUrl()in ASP.NET Framework—but be aware of its limitations. For stronger validation, use a whitelist of allowed hosts or regular expressions that enforce scheme, host, and port. - Avoid using user-controlled URLs directly in
Redirect(). Instead, map user input to predefined actions or pages. - In ASP.NET Core, use
LocalRedirect()which internally validates that the URL is local (same scheme, host, and port).
Example of a vulnerable login action:
[HttpPost]
public IActionResult Login(LoginViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
// ... authentication logic ...
return Redirect(returnUrl); // UNSAFE
}
return View(model);
}
Fixed version using LocalRedirect() and fallback:
[HttpPost]
public IActionResult Login(LoginViewModel model, string returnUrl)
{
if (ModelState.IsValid)
{
// ... authentication logic ...
if (Url.IsLocalUrl(returnUrl))
{
return LocalRedirect(returnUrl);
}
// Fallback to home page if returnUrl is not local
return LocalRedirect("/");
}
return View(model);
}
For ASP.NET Framework, implement a custom validation method:
private bool IsSafeUrl(string url)
{
if (string.IsNullOrEmpty(url)) return false;
Uri uri;
if (!Uri.TryCreate(url, UriKind.Absolute, out uri))
return false;
// Allow only https and same host
return uri.Scheme == Uri.UriSchemeHttps &
string.Equals(uri.Host, Request.Url.Host, StringComparison.OrdinalIgnoreCase);
}
// Usage
if (IsSafeUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return Redirect("/");
}
To prevent chains, ensure that any intermediate service (e.g., a payment gateway or SSO endpoint) also validates redirect URLs. Do not rely on a single validation point. Use middleware or filters to centralize redirect validation across controllers. For example, in ASP.NET Core, create an IAuthorizationFilter that checks redirect parameters on every request to sensitive endpoints.
Finally, leverage middleBrick’s continuous monitoring (available in Pro and Enterprise tiers) to regularly scan APIs for reintroduced regressions. The GitHub Action can be configured to fail pull requests if a scan detects an open redirect, preventing vulnerable code from merging.