Dangling Dns in Aspnet with Bearer Tokens

A dangling DNS record in an ASP.NET application becomes a security risk when services or clients rely on a hostname that resolves inconsistently, especially when Bearer Token authentication is used. If a backend microservice or external identity provider is accessed by hostname and that hostname later points to an unintended IP, tokens issued for the original service may be sent to an unexpected endpoint. Because Bearer Tokens are typically validated only at the application layer without strict host verification, an attacker who can influence DNS resolution may redirect token-bound requests to a malicious host that accepts and inspects them.

ASP.NET applications using HttpClient or RestClient without explicit endpoint validation are particularly susceptible. For example, if the application resolves a service URL from configuration or environment variables and that value is a hostname with a dangling or mutable DNS record, runtime resolution may point to a different server after a DNS change. When the application sends an Authorization header containing a Bearer Token to that resolved address, the token may be accepted by an unintended host that does not enforce strict origin checks. This can facilitate token interception, replay, or confusion with another service that also accepts the same token format.

The combination is amplified when tokens are issued for a specific audience (aud) claim that matches a hostname, and the client does not validate that the hostname matches the expected DNS records or certificate subject. If a dangling record resolves to an attacker-controlled host, the attacker may present a valid certificate for another domain and still receive the token if the client does not enforce hostname-to-certificate binding. Because the ASP.NET runtime may not enforce strict hostname verification for Bearer Token usage out of the box, developers must explicitly validate the authorization server’s hostname and ensure DNS records remain stable and authoritative.

middleBrick detects this class of issue by correlating OpenAPI/Swagger spec definitions with runtime behavior, including host resolution and Authorization header usage. The scanner flags scenarios where Bearer Token authentication is present and the target host is associated with unresolved or inconsistent DNS records, highlighting the risk of token misdelivery. Findings include severity, contextual details, and remediation guidance mapped to OWASP API Top 10 and related compliance frameworks.

Remediation centers on ensuring that Bearer Token usage includes explicit hostname validation and that HTTP clients do not follow DNS changes to unintended endpoints. In ASP.NET, prefer configuring named HttpClient instances with a fixed base address and validating the host before issuing requests. Avoid resolving hostnames dynamically at runtime for security-sensitive endpoints.

Example of insecure usage that may expose dangling DNS issues:

// Insecure: hostname resolved at runtime
var client = new HttpClient();
var token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token);
var url = $"https://{config["ServiceHost"]}/api/values"; // ServiceHost may be mutable
var response = await client.GetAsync(url);

Secure alternative with explicit host validation and fixed base address:

// Secure: fixed host with validation
var host = "api.example.com"; // Hardcode or validate against a strict allowlist
var expectedHost = new Uri(host).Host;
if (!new Uri($"https://{expectedHost}/").Host.Equals(expectedHost, StringComparison.OrdinalIgnoreCase))
{
    throw new InvalidOperationException("Invalid host configuration");
}
var client = new HttpClient { BaseAddress = new Uri($"https://{host}") };
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...");
var response = await client.GetAsync("/api/values");

When using ASP.NET Core, enforce audience and host checks in token validation parameters:

// Insecure: no host validation
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Audience = "myapi";
        options.Authority = "https://auth.example.com";
        // Missing: host validation and certificate pinning
    });

Secure token validation with host constraints:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateAudience = true,
            ValidAudience = "myapi",
            ValidateIssuer = true,
            ValidIssuer = "https://auth.example.com",
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(config["TokenKey"])),
            // Additional host validation via custom logic or IssuerValidator
        };
        options.Events = new JwtBearerEvents
        {
            OnTokenValidated = ctx =>
            {
                var reqHost = ctx.HttpContext.Request.Host.Host;
                if (!reqHost.Equals("api.example.com", StringComparison.OrdinalIgnoreCase))
                {
                    ctx.Fail("Invalid request host");
                }
                return Task.CompletedTask;
            }
        };
    });

These code patterns ensure that Bearer Token usage is bound to a stable, expected host, reducing the risk associated with dangling DNS records. middleBrick’s scans surface these patterns when spec-defined hosts differ from runtime behavior, guiding developers toward safer configurations.