Dns Rebinding in Aspnet with Basic Auth

DNS rebinding is a client-side attack where a malicious webpage resolves to an attacker-controlled IP address and then switches the underlying IP to a target host, often bypassing same-origin policies and IP-based trust assumptions. In an ASP.NET application protected with HTTP Basic Authentication, this combination can expose internal endpoints that would otherwise be considered unreachable from external clients.

When a browser makes a request to a domain protected by Basic Auth, the browser caches the provided credentials for that origin. If an attacker can cause the client to re-resolve the domain to an internal IP (for example, 127.0.0.1 or a backend service IP), the browser will still include the cached Basic Auth credentials in the request. Because the server may treat the incoming IP as trusted or may not re-validate the authorization context, it may process the request as if it originated from a trusted source, potentially exposing admin or diagnostic endpoints.

ASP.NET applications that expose internal HTTP APIs on localhost or on internal networks are at risk if they rely solely on IP-based perimeter assumptions and Basic Auth for access control. A typical vulnerable pattern is an endpoint that performs administrative actions without validating that the request originated from a trusted network or enforcing additional authorization checks. An attacker can craft a page that resolves to the public-facing domain, then via DNS rebinding, cause the victim’s browser to issue requests to internal endpoints, using the cached Basic Auth credentials to bypass authentication.

The attack flow involves multiple steps: the victim visits the attacker’s page, the attacker’s DNS infrastructure returns a public IP initially to pass browser same-origin checks, then switches to an internal IP within subsequent responses. The browser continues to send the Basic Auth header with each request, and the ASP.NET application processes commands or retrieves data that should have been protected by network segmentation or additional authorization.

To detect this with middleBrick, you can submit your public endpoint for a scan. The tool’s checks include authentication testing and SSRF-like probes that can surface whether internal endpoints are reachable when Basic Auth is used. Findings highlight risks such as missing origin validation, overly permissive CORS, or endpoints that do not enforce reauthorization for sensitive operations.

Remediation focuses on removing reliance on Basic Auth as the sole protective mechanism and ensuring that every request is validated independently of IP or origin assumptions. The following code examples show secure patterns for handling authentication and authorization in ASP.NET Core.

1. Avoid sending sensitive operations over Basic Auth without additional protections

Do not use Basic Auth for APIs that perform sensitive actions without additional context checks. Instead, use token-based schemes and ensure that each operation validates the caller’s permissions.

2. Validate Origin and Referer headers explicitly

For endpoints that accept requests from browsers, explicitly validate the Origin and Referer headers to reduce the likelihood of cross-origin abuse. This is not a complete defense but adds a layer of defense-in-depth.

app.Use(async (context, next) =>
{
    var origin = context.Request.Headers["Origin"].ToString();
    var referer = context.Request.Headers["Referer"].ToString();
    // Implement strict allow-list logic here
    if (!IsValidOrigin(origin) || !IsValidReferer(referer))
    {
        context.Response.StatusCode = 403;
        return;
    }
    await next();
});

3. Use Anti-Forgery Tokens for state-changing operations

For POST, PUT, DELETE, and other state-changing methods, use anti-forgery tokens to bind the request to the intended user session and prevent unauthorized commands from being executed via forged requests.

services.AddAntiforgery(options =>
{
    options.HeaderName = "X-CSRF-TOKEN";
});

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult PerformAction(MyModel model)
{
    // Safe processing
    return Ok();
}

4. Enforce Authorization at the resource level, not just at authentication

Use policy-based authorization to ensure that the authenticated user is allowed to perform the action on the specific resource. This prevents horizontal and vertical privilege escalation.

services.AddAuthorization(options =>
{
    options.AddPolicy("CanManageSettings", policy =>
        policy.RequireClaim("Permission", "manage_settings"));
});

[Authorize(Policy = "CanManageSettings")]
public IActionResult UpdateSettings(SettingsModel settings)
{
    // Only users with the claim can reach here
    return Ok();
}

5. Do not rely on IP address for authorization

Ensure that IP-based rules are not used as a substitute for proper authentication and authorization. If you must use IP restrictions, treat them as a temporary mitigation and not a primary control.

6. Use HTTPS and secure cookie policies

Always use HTTPS to protect credentials in transit. Configure cookie policies to prevent leakage and ensure secure handling of authentication tokens.

app.UseHttpsRedirection();
services.ConfigureApplicationCookie(options =>
{
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    options.Cookie.HttpOnly = true;
    options.Cookie.SameSite = SameSiteMode.Strict;
});

7. Prefer token-based authentication over Basic Auth for APIs

For API endpoints, use Bearer tokens with short lifetimes and scope restrictions. If you must support Basic Auth for compatibility, treat it as a transport mechanism only and enforce additional authorization checks on every request.

[Authorize(AuthenticationSchemes = "Basic")]
[Authorize(Policy = "RequireScopeApiAccess")]
public IActionResult SensitiveEndpoint()
{
    // Ensure scope and additional checks
    return Ok(new { data = "secure" });
}