Ssrf Server Side in Aspnet with Mutual Tls

Server-Side Request Forgery (SSRF) in ASP.NET applications occurs when an attacker forces the server to make arbitrary HTTP requests to internal or external endpoints. Mutual TLS (mTLS) is commonly deployed to ensure both client and server authenticate each other with X.509 certificates. While mTLS strengthens channel-level authentication, it does not remove application-level logic flaws. In fact, the presence of mTLS can create a false sense of security and affect how SSRF is detected and exploited.

In ASP.NET, an SSRF-prone implementation might use HttpClient to call downstream services, and developers may assume that mTLS protects these calls. However, if the application accepts a URL from an untrusted source (e.g., user input) and uses the server’s mTLS credentials to make that call, an attacker can induce the server to reach internal endpoints that are accessible only to mTLS-authenticated clients. Typical internal targets include metadata services (169.254.169.254), cloud provider instance metadata, internal APIs, or admin dashboards reachable only from within the network. Because the server presents a valid client certificate, the backend service grants access, bypassing network-level segregation that would otherwise block unauthenticated clients.

The combination of SSRF and mTLS also changes post-exploitation scenarios. An attacker who can control the request path may force the server to present its client certificate to internal services, potentially leading to certificate exfiltration if the application improperly handles or logs responses. Additionally, certificate validation behavior in HttpClientHandler can be misconfigured to skip hostname verification or custom certificate validation, which may further widen the attack surface. For example, blindly using ServerCertificateCustomValidationCallback without strict checks can allow connections to malicious internal endpoints.

Consider an ASP.NET endpoint that accepts a target hostname and uses mTLS to call it:

using System.Net.Http;
using System.Security.Cryptography.X509Certificates;
using System.Net.Http.Headers;

var handler = new HttpClientHandler();
handler.ClientCertificates.Add(new X509Certificate2("client.pfx", "password"));
handler.ClientCertificateOptions = ClientCertificateOption.Manual;
// WARNING: This callback disables proper validation; dangerous in production
handler.ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;

using var client = new HttpClient(handler);
var target = Request.Query["url"]; // User-controlled input
var response = await client.GetAsync(target);
return await response.Content.ReadAsStringAsync();

In this pattern, the attacker can supply an internal URL such as http://169.254.169.254/latest/meta-data/, and the server will reach it using its mTLS client certificate. The backend service (e.g., a metadata endpoint) trusts the client certificate and returns sensitive information. Even with mTLS, there is no outbound IP whitelisting or strict URI allowlisting, so SSRF remains viable.

OpenAPI/Swagger spec analysis can highlight parameters that accept URLs and may not enforce strict validation or schema constraints. When combined with runtime findings, you can correlate whether mTLS-authenticated calls are being made to unexpected internal endpoints. Security checks such as Input Validation and Property Authorization in middleBrick can help detect whether user-supplied inputs are improperly used in outbound HTTP calls, regardless of mTLS presence.

To mitigate SSRF in ASP.NET while using mTLS, focus on input validation, network controls, and secure HttpClient usage. Do not rely on mTLS to prevent SSRF; treat it as a transport safeguard, not an application access control.

• Validate and allowlist target hosts: Maintain a strict allowlist of permitted hostnames or IP ranges. Reject any user-supplied target that is not on the list.
• Restrict outbound destinations: Use network policies (firewalls, egress filtering) to limit which endpoints the server can reach. For cloud environments, block access to metadata services from application workloads.
• Use typed clients and named options: Configure HttpClient with predefined base addresses and avoid concatenating user input to paths.
• Enforce certificate validation: Avoid disabling certificate validation. Use custom validation only for controlled scenarios, and ensure hostname verification is enabled.
• Disable unnecessary client certificates for internal calls: If certain internal services do not require client certificates, do not present them, reducing exposure if a certificate is compromised.

Secure ASP.NET example with host allowlisting and proper certificate handling:

using System.Net.Http;
using System.Security.Cryptography.X509Certificates;
using Microsoft.Extensions.Options;

public class SecureApiService
{
    private readonly HttpClient _httpClient;
    private readonly HashSet _allowedHosts = new() { "api.internal.example.com", "data.internal.example.com" };

    public SecureApiService(HttpClient httpClient)
    {
        _httpClient = httpClient;
        // Load client certificate securely (e.g., from Azure Key Vault or configuration)
        var cert = new X509Certificate2("client.pfx", "password");
        _httpClient.DefaultRequestHeaders.Add("x-api-version", "v1");
        // Proper mTLS setup
        if (!_httpClientHandler.ClientCertificates.Contains(cert))
        {
            _httpClientHandler.ClientCertificates.Add(cert);
        }
        _httpClientHandler.ClientCertificateOptions = ClientCertificateOption.Manual;
        // Use custom validation that enforces policy
        _httpClientHandler.ServerCertificateCustomValidationCallback = ValidateServerCertificate;
    }

    private bool ValidateServerCertificate(HttpRequestMessage request, X509Certificate2 certificate, X509Chain chain, System.Net.Security.SslPolicyErrors errors)
    {
        // Enforce strict validation; do not accept any certificate in production
        if (errors != System.Net.Security.SslPolicyErrors.None)
        {
            return false;
        }
        // Additional custom checks can be added here
        return true;
    }

    public async Task<string> CallAllowedServiceAsync(string host, string path)
    {
        if (!_allowedHosts.Contains(host, StringComparer.OrdinalIgnoreCase))
        {
            throw new ArgumentException("Target host is not allowed");
        }
        var uri = new UriBuilder("https", host, 443, path).Uri;
        var response = await _httpClient.GetAsync(uri);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

In this approach, the application validates both the hostname and the server certificate. Even if an attacker provides a URL, the allowlist check prevents the request from reaching internal endpoints. Network-level egress controls provide defense-in-depth, ensuring that the container or host cannot reach metadata services regardless of application logic errors.

middleBrick can support this remediation workflow by scanning your ASP.NET endpoints and identifying SSRF-prone parameters that accept arbitrary URLs. Findings are mapped to relevant checks such as Input Validation and Property Authorization, and remediation guidance is provided. If you use continuous monitoring, the Pro plan can help detect regressions by scanning on a configurable schedule and alerting when risk scores degrade. The GitHub Action can fail builds if a new endpoint introduces insecure outbound HTTP behavior, and the MCP Server allows you to run scans directly from your IDE during development.