Dns Rebinding in Aspnet

Dns rebinding in Aspnet applications typically exploits the trust relationship between web APIs and internal services. When an Aspnet application accepts user-supplied URLs for processing, it may inadvertently connect to internal infrastructure rather than the intended external service.

The classic Aspnet scenario involves an API endpoint that accepts a URL parameter, fetches content from that URL, and processes the response. Consider this vulnerable pattern:

[HttpGet("/api/fetch")]
public async Task<ActionResult> FetchContent([FromQuery] string url)
{
    var httpClient = new HttpClient();
    var response = await httpClient.GetAsync(url);
    var content = await response.Content.ReadAsStringAsync();
    return Ok(content);
}

An attacker registers a domain (evil.com) and configures DNS with a short TTL. The DNS initially resolves to their external IP, but after the client's DNS cache expires, it switches to an internal IP like 192.168.1.1. When the Aspnet application processes the URL, it connects to the internal service instead of the external one.

Common Aspnet-specific manifestations include:

• Open redirect endpoints that fetch content from user-supplied URLs
• Webhook processing endpoints that call back to attacker-controlled URLs
• API proxies that forward requests to external services
• Health check endpoints that ping URLs
• RSS/Atom feed processors that fetch external content

The Aspnet HttpClient.DefaultRequestHeaders automatically adds the machine's host header, which can help attackers fingerprint internal infrastructure. Additionally, Aspnet's Kestrel server running on Windows may have different network resolution behaviors compared to Linux, affecting how DNS rebinding is exploited.

Detecting Dns rebinding in Aspnet requires both runtime monitoring and static analysis. For runtime detection, middleBrick's black-box scanning approach is particularly effective because it tests the unauthenticated attack surface without requiring credentials.

middleBrick scans for Dns rebinding by:

• Analyzing endpoints that accept URL parameters and make outbound HTTP requests
• Checking for missing URL validation or allowlist restrictions
• Testing whether the application properly validates the resolved IP address
• Scanning for endpoints that could be used for SSRF, which often overlap with Dns rebinding vulnerabilities

The scanner specifically looks for Aspnet patterns like:

// Vulnerable Aspnet pattern detected
[HttpPost("/api/webhook")]
public async Task<ActionResult> ProcessWebhook([FromBody] WebhookRequest request)
{
    var client = new HttpClient();
    var response = await client.GetAsync(request.CallbackUrl); // No validation!
    return Ok();
}

For manual detection, Aspnet developers should:

• Search code for HttpClient usage with user-supplied URLs
• Check for missing IP allowlists or network restrictions
• Look for endpoints with [AllowAnonymous] attributes that process external content
• Review startup.cs for missing CORS or network security configurations

middleBrick's OpenAPI analysis can also detect Dns rebinding risks by examining API specifications for endpoints that accept URLs or external references, then correlating this with runtime scanning results.

Remediating Dns rebinding in Aspnet requires a defense-in-depth approach. The most effective strategy combines input validation, network restrictions, and proper configuration.

First, implement strict URL validation using Aspnet's built-in features:

public class ValidatedUrlAttribute : ValidationAttribute
{
    private static readonly HashSet<string> _allowedSchemes = 
        new() { "https" };
    
    protected override ValidationResult IsValid(object value, ValidationContext validationContext)
    {
        if (value == null) return ValidationResult.Success;
        
        if (value is not string url) 
            return new ValidationResult("URL must be a string");
        
        if (!Uri.TryCreate(url, UriKind.Absolute, out var uri))
            return new ValidationResult("Invalid URL format");
        
        if (!_allowedSchemes.Contains(uri.Scheme))
            return new ValidationResult("Only HTTPS URLs are allowed");
        
        return ValidationResult.Success;
    }
}

// Usage in controller
[HttpGet("/api/fetch")]
public async Task<ActionResult> FetchContent(
    [FromQuery, ValidatedUrl] string url,
    [FromServices] IHttpClientFactory clientFactory)
{
    var client = clientFactory.CreateClient();
    var response = await client.GetAsync(url);
    return Ok(await response.Content.ReadAsStringAsync());
}

Next, implement IP allowlisting using Aspnet's middleware pipeline:

public class IPAllowlistMiddleware
{
    private readonly HashSet<string> _allowedIPs = new()
    {
        // Allow external services only
        "93.184.216.34", // example.com
        "151.101.129.69" // reddit.com
    };
    
    private readonly RequestDelegate _next;
    
    public IPAllowlistMiddleware(RequestDelegate next)
    {
        _next = next;
    }
    
    public async Task InvokeAsync(HttpContext context)
    {
        var endpoint = context.GetEndpoint();
        if (endpoint?.Metadata.GetMetadata<AllowExternalUrlAttribute>() != null)
        {
            var url = context.Request.Query["url"];
            if (!string.IsNullOrEmpty(url))
            {
                if (!Uri.TryCreate(url, UriKind.Absolute, out var uri))
                {
                    context.Response.StatusCode = 400;
                    return;
                }
                
                var ip = await Dns.GetHostAddressesAsync(uri.Host);
                if (ip.Any(i => !_allowedIPs.Contains(i.ToString())))
                {
                    context.Response.StatusCode = 403;
                    return;
                }
            }
        }
        
        await _next(context);
    }
}

// Extension method for easy registration
public static class IPAllowlistExtensions
{
    public static IApplicationBuilder UseIPAllowlist(
        this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<IPAllowlistMiddleware>();
    }
}

Finally, configure network security in Aspnet's configuration files:

// appsettings.json
{
  "NetworkSecurity": {
    "AllowedDomains": [
      "api.example.com",
      "service.example.net"
    ],
    "BlockedCIDRs": [
      "10.0.0.0/8",
      "192.168.0.0/16",
      "172.16.0.0/12"
    ]
  }
}

For production deployments, consider using Aspnet's built-in rate limiting and request validation features to further reduce the attack surface.