Dangling Dns in Aspnet with Hmac Signatures

A dangling DNS record occurs when a hostname (e.g., int-api.example.com) previously pointed to an environment or service but now resolves to an unexpected or unmanaged destination. In ASP.NET applications that use HMAC signatures for request authentication, this combination can expose a critical security risk if the application validates the signature but does not sufficiently validate the origin or ownership of the hostname used in the signed payload.

Consider an ASP.NET Core API that signs requests using an HMAC derived from a shared secret and includes a hostname or subdomain value as part of the signed string. If the application resolves a user-supplied host header or URL to a dangling DNS record, the signature validation may still pass while the request is routed to an unintended host. Attackers can register or inherit the dangling hostname, enabling host or server confusion attacks, request smuggling, or unauthorized routing to malicious infrastructure that accepts valid HMAC-signed traffic.

For example, an API might sign a canonical string composed of HTTP method, path, timestamp, and hostname. If the hostname used in the signature is taken from the request Host header and the DNS record for that host is dangling, an attacker who can make the dangling host resolve to their server can replay captured signed requests. Because HMAC verification succeeds, the API may treat the request as legitimate and route it based on the validated but now-malicious hostname, bypassing intended routing or tenant isolation.

In the context of middleBrick’s checks, this scenario surfaces as a finding in the BOLA/IDOR or Property Authorization categories when hostname ownership and request integrity are not independently verified. The scanner tests whether signed requests that include a hostname can be replayed when DNS points to an attacker-controlled endpoint, highlighting the absence of hostname pinning or strict DNS validation alongside HMAC verification.

To detect this during a scan, middleBrick runs active probes that include signed requests with controlled hostnames and inspects whether the application enforces hostname binding before trusting the HMAC. The tool also cross-references OpenAPI/Swagger specs (with full $ref resolution) to verify whether host variables and security schemes explicitly account for dangling DNS risks. Findings include severity ratings and remediation guidance mapped to frameworks such as OWASP API Top 10 and PCI-DSS.

Remediation focuses on ensuring the hostname used in HMAC computation is authoritative, immutable, and validated independently of external inputs such as the Host header. Do not rely solely on signature verification; bind the expected hostname or canonical target to the application configuration and verify it before processing the request.

1. Use a configured, pinned hostname instead of the request Host header

Define an allowed hostname in configuration and use it when constructing and verifying the canonical string for HMAC. This prevents an attacker from influencing which hostname is included in the signature.

// Example: pinned hostname in configuration and usage in signature validation
public static class SecurityConfig
{
    public const string AllowedHost = "api.example.com";
    public const string SharedSecret = "your-256-bit-secret-here-32bytes-1234567890ab";
}

public bool ValidateHmacRequest(HttpRequest request)
{
    var timestamp = request.Headers["x-timestamp"].ToString();
    var receivedSignature = request.Headers["x-hmac-sha256"].ToString();
    var canonical = $"POST:{request.Path}:{timestamp}:{SecurityConfig.AllowedHost}";
    var computedSignature = ComputeHmacSha256(canonical, SecurityConfig.SharedSecret);
    return SecureCompare(computedSignature, receivedSignature);
}

private static string ComputeHmacSha256(string data, string key)
{
    using var hmac = new System.Security.Cryptography.HMACSHA256(Convert.FromBase64String(key));
    var hash = hmac.ComputeHash(System.Text.Encoding.UTF8.GetBytes(data));
    return Convert.ToBase64String(hash);
}

private static bool SecureCompare(string a, string b)
{
    return System.Security.Cryptography.MacCertificateHelper.SecureEquals(a, b);
}

2. Validate DNS resolution and optionally pin records

Before accepting a request, resolve the hostname you expect (from configuration) and ensure it resolves consistently. For stronger assurance, pin DNS records or use certificate transparency logs in advanced deployments, but at minimum ensure the resolved IP aligns with your expectations and that the hostname is not CNAME or alias chaining to unexpected targets.

// Example: ensure the configured hostname resolves to expected endpoints
using System.Net;

public bool IsValidHost(string hostname, string[] expectedIps)
{
    var hostEntry = Dns.GetHostEntry(hostname);
    var addresses = hostEntry.AddressList.Select(a => a.ToString()).ToArray();
    return expectedIps.All(addresses.Contains);
}

3. Include a nonce or timestamp tightly coupled with hostname

Bind a short-lived timestamp or nonce to the hostname in the signed payload and enforce strict replay windows. This limits the usefulness of captured requests when DNS is dangling and reduces replay risk.

// Example: timestamp-based replay protection with hostname binding
public bool ValidateWithReplayProtection(HttpRequest request)
{
    const int windowSeconds = 30;
    if (!long.TryParse(request.Headers["x-timestamp"], out var timestampSeconds))
        return false;
    var now = DateTimeOffset.UtcNow.ToUnixTimeSeconds();
    if (Math.Abs(now - timestampSeconds) > windowSeconds)
        return false;
    var canonical = $"POST:{request.Path}:{timestampSeconds}:{SecurityConfig.AllowedHost}";
    var computedSignature = ComputeHmacSha256(canonical, SecurityConfig.SharedSecret);
    return SecureCompare(computedSignature, request.Headers["x-hmac-sha256"]);
}

These examples illustrate how to combine HMAC signature validation with explicit hostname controls to mitigate risks introduced by dangling DNS records. The guidance aligns with findings reported by middleBrick, which maps such issues to compliance frameworks and provides prioritized remediation steps without claiming to automatically fix or block requests.