Dns Rebinding in Aspnet (Csharp)

DNS rebinding is a client-side attack where a malicious webpage causes a victim’s browser to send requests to an internal IP address that the victim can reach but external hosts cannot. In an ASP.NET application, this can occur when the server acts as a proxy or when the client-side JavaScript running in the victim’s browser is allowed to make requests back to the server or other origins without proper origin validation. Because ASP.NET often hosts APIs consumed by web clients, an attacker can use a rebinding domain to bypass same-origin policies and trick the client into accessing internal endpoints.

With C#, the risk surfaces in a few concrete patterns. If your ASP.NET Core app exposes endpoints that accept a hostname or URL from the client and then perform outbound HTTP requests (for example using HttpClient), an attacker can supply an internal IP such as 127.0.0.1 or a corporate service IP. Even if the server validates the hostname in C# (e.g., using Uri checks), the browser’s DNS resolution happens before the request leaves the victim’s machine, allowing the attacker to serve a page that makes the browser resolve a domain to an internal IP after the initial request. If the endpoint relies only on C#-side validation without strict client-origin enforcement, the request appears legitimate to the server but originates from a malicious page.

The ASP.NET runtime itself does not inherently prevent DNS rebinding; it is the combination of permissive C# proxy logic and weak client-side or network controls that enables the issue. For instance, consider a C# controller that forwards requests to a user-supplied host:

var uri = new Uri($"{userHost}/api/resource"); // userHost supplied by request
using var client = new HttpClient();
var response = await client.GetAsync(uri);

If userHost is not strictly validated against an allowlist and the resolver in the victim’s browser is manipulated, the request can be directed to internal services. Attackers can chain this with a public-facing page that uses DNS rebinding to iterate through IP ranges or to reach internal management interfaces. Because the scan tests unauthenticated attack surfaces, middleBrick flags such endpoints under BOLA/IDOR and Input Validation checks, correlating C# host-resolution behavior with the runtime exposure seen by the browser.

To detect this during a scan, middleBrick’s 12 security checks run in parallel, including Input Validation, BOLA/IDOR, and Unsafe Consumption. These checks correlate client-side network behavior with server-side Csharp patterns (such as unchecked outbound calls and missing origin verification) to surface findings with severity and remediation guidance. middleBrick does not fix the code; it highlights the risk and points you toward hardening the endpoint and the client.

Remediation focuses on strict input validation, avoiding blind forwarding to user-supplied hosts, and enforcing same-origin or strict allowlists on the server and client. Below are concrete C# examples for ASP.NET Core that reduce the attack surface for DNS rebinding.

1. Avoid forwarding to user-supplied hosts

The safest approach is to not accept a hostname for outbound calls. If you must, use a strict allowlist of domains and IPs and resolve the target before making the request.

public IActionResult GetResource(string host)
{
    // Allowlist: only these origins are permitted
    var allowedHosts = new HashSet<string>("api.mycompany.com", "10.0.0.1");
    if (!allowedHosts.Contains(host, StringComparer.OrdinalIgnoreCase))
    {
        return BadRequest("Host not allowed");
    }

    var uri = new UriBuilder(Uri.UriSchemeHttps, host, 443, "/api/resource").Uri;
    using var client = new HttpClient();
    var response = await client.GetAsync(uri);
    var content = await response.Content.ReadAsStringAsync();
    return Content(content, "application/json");
}

2. Use HttpClient with a custom HttpMessageHandler to restrict IPs

You can enforce that requests do not target private IP ranges by inspecting the resolved endpoint in a handler.

public class PrivateIpValidationHandler : DelegatingHandler
{
    protected override async Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request, CancellationToken cancellationToken)
    {
        var host = request.RequestUri?.Host;
        if (!string.IsNullOrEmpty(host) && IPAddress.TryParse(host, out var address))
        {
            // Reject private ranges
            if (address.IsPrivate())
            {
                throw new HttpRequestException("Private IP addresses are not allowed");
            }
        }
        return await base.SendAsync(request, cancellationToken);
    }
}

// Usage:
var handler = new PrivateIpValidationHandler { InnerHandler = new HttpClientHandler() };
using var client = new HttpClient(handler);

3. Validate and normalize URIs on the server and enforce CORS

In your ConfigureServices and Configure pipeline, enforce CORS tightly and validate origins. Combine this with server-side checks to ensure requests are not being abused via a rebindable domain.

services.AddCors(options =>
{
    options.AddPolicy("StrictPolicy", policy =>
    {
        policy.WithOrigins("https://mytrusted.com")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

app.UseCors("StrictPolicy");

On the client, ensure that browser same-origin policies are respected by avoiding wildcard CORS and by using credentials only where necessary. middleBrick’s checks for CORS misconfiguration and Input Validation map well to these practices, showing how C# server logic and browser behavior interact.

By combining server-side allowlists, rejection of private IPs, and tight CORS, you reduce the window for DNS rebinding in an ASP.NET + Csharp stack. middleBrick can highlight endpoints where user-controlled hosts or missing origin checks increase risk, guiding you toward safer patterns.