Ssrf Server Side in Aspnet (Csharp)

Server-side request forgery (SSRF) in ASP.NET applications written in Csharp occurs when an attacker can coerce the server into making arbitrary outbound HTTP requests. In ASP.NET, this commonly arises when user-controlled input is passed to .NET classes that perform web requests, such as HttpClient, WebClient, or HttpWebRequest. For example, if an endpoint accepts a URL parameter to fetch external resources without strict validation, an attacker can supply internal endpoints, metadata services, or cloud instance metadata URLs (http://169.254.169.254 for AWS, http://metadata.google.internal for GCP) and reach services otherwise unreachable from the internet.

ASP.NET APIs built with Csharp often expose SSRF through seemingly benign functionality: fetching avatars, webhooks, status checks, or importing remote configurations. Because the server-side code runs with the identity of the application pool, SSRF can lead to internal service enumeration, access to cloud metadata, or pivoting into private networks. The risk is amplified when the application uses default trust configurations, does not restrict outbound destinations, or forwards user input directly to HttpClient without validation. Attack patterns include using encoded or nested URLs, leveraging file:// or gopher:// schemes, and abusing timeouts or SSRF-to-SSRF chains within containerized environments.

middleBrick scans such endpoints in black-box mode, testing for SSRF by probing for unauthenticated reachability to internal IP ranges and sensitive cloud metadata endpoints. When an API is discoverable via an OpenAPI/Swagger spec, the scanner cross-references spec definitions with runtime behavior to highlight risky routes that accept arbitrary URLs. This is especially relevant for Csharp ASP.NET services that expose dynamic fetching without authentication, as unauthenticated LLM endpoints can also be targeted for data exfiltration when SSRF combines with insecure AI integrations.

Remediation centers on strict input validation, allowlisting destinations, and avoiding direct forwarding of user input to web request APIs. Prefer using strongly typed configuration for allowed domains and prefer built-in defenses like IHttpClientFactory with typed clients to centralize policies. Never pass raw user input to HttpClient or WebClient; instead, map user intent to internal or vetted external actions.

Example: Unsafe dynamic fetch (vulnerable)

// ❌ Vulnerable: user-controlled URL passed directly
[HttpGet("fetch")]
public async Task<IActionResult> Fetch(string url)
{
    using var client = new HttpClient();
    var response = await client.GetAsync(url);
    var content = await response.Content.ReadAsStringAsync();
    return Content(content);
}

Example: Safe allowlist-based fetch (recommended)

// ✅ Safe: allowlist domains, validate scheme and host
private static readonly HashSet<string> AllowedHosts = new(StringComparer.OrdinalIgnoreCase)
{
    "api.github.com",
    "api.example.com"
};

[HttpGet("fetch")]
public async Task<IActionResult> Fetch(Uri uri)
{
    if (uri == null || !uri.IsWellFormedOriginalString())
        return BadRequest("Invalid URI");

    if (!AllowedHosts.Contains(uri.Host))
        return Forbid("Destination not allowed");

    // Optional: enforce HTTPS
    if (uri.Scheme != Uri.UriSchemeHttps)
        return BadRequest("Only HTTPS allowed");

    using var client = new HttpClient();
    var response = await client.GetAsync(uri);
    response.EnsureSuccessStatusCode();
    var content = await response.Content.ReadAsStringAsync();
    return Content(content);
}

Additional hardening practices

• Use IHttpClientFactory to configure timeouts, policies, and DNS refresh centrally.
• Disable automatic redirection (HttpClientHandler.AllowAutoRedirect = false) to prevent open redirect–style SSRF chains.
• Restrict outbound connectivity via network policies (firewall/container networking) to deny access to metadata IPs.
• Sanitize and reject dangerous schemes (file://, gopher://, dict://) explicitly.
• Apply defense in depth: combine allowlisting, outbound ACLs, and runtime monitoring.

middleBrick complements these fixes by detecting SSRF findings and mapping them to frameworks like OWASP API Top 10 and PCI-DSS. With the Pro plan, continuous monitoring can alert you if a newly introduced endpoint becomes vulnerable, and the GitHub Action can fail builds when risk scores exceed your threshold.