Dns Rebinding in Aspnet
How Dns Rebinding Manifests in Aspnet
DNS rebinding attacks exploit the browser's same-origin policy by tricking a victim's browser into resolving a domain to an attacker-controlled IP address, then rapidly changing the DNS record to point to an internal IP (like 127.0.0.1 or 192.168.x.x). In ASP.NET applications, this becomes dangerous when the application trusts the Host header or uses domain-based logic for security decisions without proper validation.
A common vulnerable pattern in ASP.NET Core is using the Request.Host value to construct redirect URLs, generate absolute links, or make trust decisions. For example, consider a middleware that redirects based on the host:
public class HostBasedRedirectMiddleware
{
private readonly RequestDelegate _next;
public HostBasedRedirectMiddleware(RequestDelegate next) => _next = next;
public async Task InvokeAsync(HttpContext context)
{
var host = context.Request.Host.Host; // Vulnerable: uses raw host value
if (host.Equals("trusted.internal", StringComparison.OrdinalIgnoreCase))
{
context.Response.Redirect("https://" + host + "/sensitive");
return;
}
await _next(context);
}
}
If an attacker controls a domain (e.g., attacker.com) and can manipulate its DNS TTL to a low value, they can first point attacker.com to their server to serve malicious JavaScript, then rebind the domain to 127.0.0.1. The victim's browser, believing it's still communicating with attacker.com due to same-origin policy, can now make requests to localhost services (like https://localhost:5000) that the ASP.NET app might expose during development or misconfigured production.
Another vector is in OAuth callback handling where the redirect URI is validated by comparing against a list of allowed hosts using string comparison on the Request.Host value without proper canonicalization or IP address rejection.
Aspnet-Specific Detection
Detecting DNS rebinding vulnerabilities in ASP.NET applications requires observing how the application handles the Host header and whether it performs adequate validation before using it in security-sensitive contexts. middleBrick identifies this during its unauthenticated black-box scan by:
- Sending requests with varying
Hostheader values (including localhost, private IPs, and attacker-controlled domains) to endpoints that perform redirects, generate absolute URLs, or make trust decisions based on the host. - Checking for reflections of the
Host value in responses (e.g., in Location headers, JSON bodies, or JavaScript) without sanitization or validation against a strict allowlist. - Testing for inconsistent behavior when the
Host is set to an IP address versus a domain name, which can indicate insufficient validation.
For example, if a scan sends a request with Host: 127.0.0.1:5000 to an ASP.NET endpoint and receives a redirect to http://127.0.0.1:5000/admin in the Location header, middleBrick flags this as a potential DNS rebinding vector. The scanner correlates this with the absence of host validation logic (like checking against a known list of allowed hosts or verifying the host is not a private IP).
middleBrick’s OpenAPI/Swagger analysis further aids detection by identifying endpoints that accept or reflect host-derived data (e.g., parameters used in UriBuilder or RedirectToAction) and cross-referencing them with runtime findings to confirm exploitable paths.
Aspnet-Specific Remediation
Fixing DNS rebinding vulnerabilities in ASP.NET applications involves validating the Host header early in the request pipeline and rejecting any value that does not strictly match an allowed list of domains or IP addresses. ASP.NET Core provides built-in features to assist with this.
The primary defense is to implement host validation middleware that runs early in the pipeline. This middleware should:
- Extract the
Hostheader value. - Validate it against a strict allowlist of known, trusted hosts (e.g.,
api.example.com,www.example.com). - Reject requests with unrecognized hosts (returning 400 Bad Request) before they reach application logic.
- Additionally, explicitly reject IP addresses in the
Hostheader to prevent direct IP-based rebinding attempts.
Here is a syntactically correct ASP.NET Core middleware implementation:
public class HostValidationMiddleware
{
private readonly RequestDelegate _next;
private readonly HashSet _allowedHosts = new HashSet(StringComparer.OrdinalIgnoreCase)
{
"api.example.com",
"www.example.com"
};
public HostValidationMiddleware(RequestDelegate next) => _next = next;
public async Task InvokeAsync(HttpContext context)
{
var host = context.Request.Host.Host;
// Reject if host is an IP address (IPv4 or IPv6)
if (IPAddress.TryParse(host, out _))
{
context.Response.StatusCode = 400;
await context.Response.WriteAsync("Invalid host header");
return;
}
// Reject if host not in allowed list
if (!_allowedHosts.Contains(host))
{
context.Response.StatusCode = 400;
await context.Response.WriteAsync("Invalid host header");
return;
}
await _next(context);
}
}
// In Program.cs
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.UseMiddleware();
// ... rest of pipeline
app.Run();
For ASP.NET applications relying on IIS, similar validation can be configured via requestFiltering in web.config to deny requests based on host headers, though middleware provides more flexibility. After implementing validation, rescan with middleBrick to confirm the Host header is now properly rejected for untrusted values, eliminating the DNS rebinding vector.
Frequently Asked Questions
Can DNS rebinding affect ASP.NET applications that only use HTTPS?
Host header for security decisions (e.g., redirect URI validation in OAuth), an attacker can rebind a domain to localhost and make same-origin requests to https://localhost:5000 even if the service only listens on HTTPS. The attack works as long as the victim's browser believes it is interacting with the original domain due to DNS timing.Does ASP.NET Core's built-in host validation in <code>UseForwardedHeaders</code> prevent DNS rebinding?
UseForwardedHeaders is designed to correctly interpret X-Forwarded-For and X-Forwarded-Proto headers when behind a proxy, but it does not validate or restrict the Host header itself. Relying on it alone leaves the application vulnerable to DNS rebinding if application logic uses the raw Host value without additional validation. Explicit host validation middleware is required.