Dns Rebinding in Aspnet (Csharp)

DNS rebinding is a client-side attack where an attacker tricks a victim’s browser into resolving a domain name to an internal IP address that the victim can reach, such as 127.0.0.1 or an internal service. In an ASP.NET application served over HTTP, if the application does not enforce strict origin checks and relies only on DNS-based access assumptions, a malicious page can pivot the browser to interact with the local server on behalf of the user. When C# ASP.NET code uses the client’s IP or hostname to make authorization decisions—such as allowing localhost calls from JavaScript or trusting the Host header—this creates a path for rebinding to bypass intended network boundaries.

Consider an ASP.NET Core endpoint written in C# that permits management actions only from localhost:

app.MapGet("/admin/reset", (HttpContext context) =>
{
    if (!context.Connection.RemoteIpAddress?.ToString() == "127.0.0.1")
    {
        return Results.Forbid();
    }
    // perform reset
    return Results.Ok("Reset");
});

An attacker can host a page that performs a DNS rebind to move from a public hostname to 127.0.0.1. If the ASP.NET app does not also validate the Origin or Referer header, and if the browser sends cookies for the site, the request may appear to come from a trusted origin. Because the check above uses only the remote IP, which the browser controls during rebinding, the request can be made to appear as if it originates from localhost, leading to unauthorized state changes or information disclosure.

ASP.NET applications that dynamically construct URLs or redirect based on user input are also at risk. For example, returning a redirect to a value provided by the client can be abused if the client resolves to an internal host during rebinding:

var redirectUrl = Request.Query["url"];
if (Uri.TryCreate(redirectUrl, UriKind.Absolute, out var uri))
{
    return Redirect(uri.ToString());
}

Without validating that the target is external and not a private or loopback address, an attacker can cause the victim’s browser to POST or GET internal endpoints, effectively turning the victim into a proxy for internal reconnaissance. Because ASP.NET may expose endpoints for health checks or debugging on localhost, rebinding can enumerate internal services by chaining C# logic with browser behavior.

To reliably detect this class of issue during scans, middleBrick tests whether an endpoint reflects or redirects based on attacker-controlled inputs while also probing for SSRF-like behaviors that pair well with rebinding. The tool also inspects OpenAPI/Swagger specs (2.0, 3.0, 3.1) with full $ref resolution to see whether localhost or internal references appear in paths or security schemes, cross-referencing these definitions with runtime findings to highlight mismatches between intended access and exposed surfaces.

Remediation focuses on never trusting the client’s notion of network location or origin. In C# ASP.NET, validate server-side using a combination of host binding configuration, strict referer/origin checks, and explicit allowlists for external targets. Avoid relying on RemoteIpAddress alone for security decisions, and do not redirect to user-supplied URLs without strict validation.

1) Bind services only to explicitly configured interfaces and disable loopback shortcuts in configuration:

// Program.cs
builder.WebHost.UseUrls("http://0.0.0.0:5000"); // bind to external interface only
// Do not use UseUrls with "localhost" or "127.0.0.1" for public endpoints

2) Validate the Origin and Referer headers for state-changing requests, and reject known internal targets:

app.MapPost("/api/action", (HttpRequest request, HttpResponse response) =>
{
    var origin = request.Headers["Origin"].ToString();
    var referer = request.Headers["Referer"].ToString();
    if (!IsValidExternalOrigin(origin, referer))
    {
        return Results.Unauthorized();
    }
    // proceed with action
    return Results.Ok();
});

bool IsValidExternalOrigin(string origin, string referer)
{
    var allowed = new[] { "https://trusted.example.com" };
    return allowed.Contains(origin) || allowed.Contains(referer);
}

3) Sanitize redirects and avoid open redirects by resolving and validating targets:

app.MapGet("/go", (HttpRequest request) =>
{
    var userUrl = request.Query["url"].ToString();
    if (Uri.TryCreate(userUrl, UriKind.Absolute, out var uri) && IsExternalAllowed(uri))
    {
        return Results.Redirect(uri.ToString());
    }
    return Results.BadRequest("Invalid target");
});

bool IsExternalAllowed(Uri uri)
{
    // reject private, loopback, and local addresses
    if (!uri.IsAbsoluteUri) return false;
    var host = uri.DnsSafeHost;
    if (IPAddress.TryParse(host, out var address))
    {
        return !address.IsLocal();
    }
    // optionally allow only specific external domains
    return host.EndsWith("example.com", StringComparison.OrdinalIgnoreCase);
}

4) Use endpoint routing constraints to reject requests that resolve to internal IPs at the routing level. For host headers that may be ambiguous, enforce a strict list of allowed hosts in configuration.

// appsettings.json
AllowedHosts: "api.example.com;www.example.com"

// Program.cs
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddRouting(options => options.LowercaseUrls = true);

These Csharp-focused steps ensure that even if a browser is tricked via DNS rebinding, the server-side logic does not inadvertently grant elevated access to internal services. middleBrick scans verify these controls by testing unauthenticated attack surfaces and, when using the Pro plan, enables continuous monitoring so changes that weaken these checks can trigger alerts before exposure.