Ssrf Blind in Aspnet (Csharp)

Server-Side Request Forgery (SSRF) in ASP.NET with C# typically arises when an application constructs HTTP requests using user-controlled input without adequate validation or isolation. In C# ASP.NET, common patterns such as HttpClient, WebClient, or HttpWebRequest are often used to call external services. If an endpoint accepts a URL parameter and passes it directly to these clients without restricting targets, an attacker can induce blind SSRF.

A classic example is a metadata or health-check endpoint that fetches a remote resource based on a query parameter:

// Vulnerable pattern in ASP.NET with C#
[HttpGet("/api/lookup")]
public async Task<IActionResult> Lookup(string url)
{
    using var client = new HttpClient();
    var response = await client.GetAsync(url);
    var content = await response.Content.ReadAsStringAsync();
    return Ok(content);
}

An attacker can supply values such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS instance metadata) or internal services like http://localhost:8080 to probe the environment. Because the response is not returned directly and may be processed silently (e.g., parsed for specific headers or status codes), this becomes a blind SSRF. The C# runtime does not inherently prevent connections to internal endpoints, so the onus is on the developer to enforce strict allowlists and network boundaries.

Blind SSRF can be leveraged for internal reconnaissance, metadata exfiltration via out-of-band techniques, or even SSRF-to-RCE when combined with other vulnerable services. In ASP.NET, additional risk arises from misconfigured Kestrel endpoints or overly permissive proxy settings that allow traversal to internal resources. The framework itself does not introduce the flaw, but its ecosystem—libraries, default configurations, and developer habits—can enable these patterns to persist undetected.

Because middleBrick tests unauthenticated attack surfaces and runs checks in parallel, it can detect SSRF indicators such as unexpected network calls to internal IP ranges or missing validation on URL inputs. Findings are mapped to the OWASP API Top 10 and include remediation guidance rather than attempting to block or fix the endpoint.

Remediation focuses on input validation, network isolation, and avoiding dynamic URL construction. In C# ASP.NET, prefer explicit configuration over user-supplied URLs. When external calls are necessary, enforce strict allowlists and use typed clients.

1. Use a hardcoded base URL with path parameters instead of a fully dynamic URL:

// Secure pattern: allowlist base, validate path segment
[HttpGet("/api/lookup")]
public async Task<IActionResult> Lookup(string resourceId)
{
    if (!Regex.IsMatch(resourceId, "^[a-zA-Z0-9_-]+$"))
    {
        return BadRequest("Invalid resource identifier");
    }
    var baseUrl = _config["AllowedExternalBaseUrl"];
    using var client = new HttpClient();
    var response = await client.GetAsync($"{baseUrl}/resources/{resourceId}");
    response.EnsureSuccessStatusCode();
    var content = await response.Content.ReadAsStringAsync();
    return Ok(content);
}

2. Configure HttpClient with a predefined HttpClientHandler that restricts proxy and local connections:

// Secure handler to prevent connections to localhost or internal ranges
var handler = new HttpClientHandler
{
    Proxy = null,
    UseProxy = false,
    CheckCertificateRevocationList = true
};
// Optionally, customize server certificate validation for additional control
handler.ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator; // Avoid in production
using var client = new HttpClient(handler);

3. For complex scenarios, use typed clients with policy-based retries and timeouts, and avoid passing raw user input into request URIs:

services.AddHttpClient<ExternalService>(client =>
{
    client.BaseAddress = new Uri(Configuration["ExternalService:BaseUrl"]);
    client.Timeout = TimeSpan.FromSeconds(5);
});

public class ExternalService
{
    private readonly HttpClient _http;
    public ExternalService(HttpClient http) => _http = http;

    public async Task<string> GetDataAsync(string allowedId)
    {
        // allowedId is pre-validated
        var response = await _http.GetAsync($"/data/{allowedId}");
        response.RequireSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

These practices align with the Secure Coding Practices for .NET and help mitigate SSRF by design. middleBrick’s scans can verify that such controls are present by analyzing OpenAPI specs and runtime behavior, providing prioritized findings with severity levels and guidance.