Broken Authentication in Aspnet with Mutual Tls

Broken Authentication in ASP.NET when combined with Mutual TLS (mTLS) often stems from configuration gaps that weaken the intended assurance of client authentication. mTLS requires both the server and the client to present valid certificates during the TLS handshake. If ASP.NET is not explicitly configured to require and validate client certificates, the runtime may accept unauthenticated or anonymous requests even when mTLS is enabled at the load balancer or reverse proxy.

For example, hosting ASP.NET behind a gateway that terminates mTLS and forwards traffic over plain HTTP to the app can create a false sense of security. The backend application may not enforce Demand or RequireCertificate checks, allowing access when the gateway incorrectly maps client certificate claims to identities. This misconfiguration maps directly to OWASP API Top 10 2023: A07 and can be discovered by scanners that test unauthenticated attack surfaces, such as middleBrick’s Authentication check.

Additionally, certificate validation logic in ASP.NET may be incomplete. Developers might accept any certificate presented by the client without verifying the subject, issuer, policy constraints, or revocation status. A vulnerable pattern looks like:

// Incomplete client certificate validation in ASP.NET Core
app.Use((context, next) =>
{
    if (context.Request.ClientCert == null)
    {
        // This check alone is insufficient
        context.Fail();
    }
    return next();
});

Without validating the certificate thumbprint, enhanced key usage, or mapping to a known identity store, an attacker who possesses a valid but stolen certificate can authenticate as that principal. This is a Broken Authentication vector because the application does not independently verify the certificate’s binding to a user or service identity. Furthermore, if session tokens or cookies issued after authentication lack proper protection (e.g., Secure, HttpOnly, strict SameSite), session hijacking becomes feasible even when mTLS is used at the edge.

middleBrick’s BOLA/IDOR and Property Authorization checks can surface indicators of broken authentication by probing endpoints without credentials and analyzing whether identity claims are enforced consistently. The tool also tests for BFLA/Privilege Escalation by attempting to access higher-privilege resources using a certificate mapped to a lower-privilege identity.

To remediate Broken Authentication when using mTLS in ASP.NET, enforce strict client certificate validation and bind certificates to identities within application logic. Below are concrete, secure code examples for ASP.NET Core.

1. Require and validate client certificates in the pipeline

Ensure the app enforces client certificate validation rather than relying solely on infrastructure termination:

// Program.cs — enforce client certificate validation
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ConfigureHttpsDefaults(httpsOptions =>
    {
        httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
        httpsOptions.AllowedClientCertificates.Add(new X509Certificate2("path/to/ca.cer"));
    });
});

var app = builder.Build();
app.Use((context, next) =>
{
    var clientCert = context.Connection.ClientCertificate;
    if (clientCert == null)
    {
        context.Response.StatusCode = 403;
        return Results.Json(new { error = "Client certificate required" }).ExecuteAsync(context);
    }
    // Validate certificate fields
    if (!IsValidClientCertificate(clientCert))
    {
        context.Response.StatusCode = 403;
        return Results.Json(new { error = "Invalid client certificate" }).ExecuteAsync(context);
    }
    // Map certificate to user/identity, e.g., by thumbprint
    context.Items["UserIdentity"] = MapCertificateToIdentity(clientCert);
    return next();
});
app.UseAuthorization();
app.MapControllers();
app.Run();

bool IsValidClientCertificate(X509Certificate2 cert)
{
    // Verify issuer, subject, policy OIDs, and revocation as required
    var chain = new X509Chain();
    chain.ChainPolicy.RevocationMode = X509RevocationMode.NoCheck; // configure per policy
    chain.ChainPolicy.ExtraStore.Add(new X509Certificate2("path/to/ca.cer"));
    chain.ChainPolicy.VerificationFlags = X509VerificationFlags.NoFlag;
    bool isValid = chain.Build(cert);
    // Additional checks: e.g., extended key usage, thumbprint allowlist
    var eku = cert.Extensions.OfType<X509EnhancedKeyUsageExtension>();
    // Implement policy-specific validation
    return isValid;
}

string MapCertificateToIdentity(X509Certificate2 cert)
{
    // Example: map by thumbprint to a user/service in your directory
    var thumbprint = cert.Thumbprint;
    // Lookup identity from a trusted source
    return $"user-{thumbprint}";
}

2. Avoid forwarding unvalidated identity claims from a gateway

If using a gateway that terminates mTLS, ensure the gateway does not strip client certificate validation. The backend should still validate the certificate or verify a signed assertion from the gateway. A safer approach is to keep mTLS enforcement at the application host:

// Example: Configure Kestrel to require client certs directly
builder.WebHost.UseUrls("https://*:5001");
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ServerCertificate = new X509Certificate2("server.pfx", "password");
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            httpsOptions.AllowedClientCertificates.Add(new X509Certificate2("path/to/ca.cer"));
        });
    });
});

3. Apply claims-based authorization after validation

Once the certificate is validated, map claims and enforce policies:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("RequireMappedIdentity", policy =>
        policy.RequireAssertion(context =>
            context.User.Identity?.IsAuthenticated == true &&
            context.User.HasClaim(c => c.Type == "scope" && c.Value.Contains("api_access"))
        )
    );
});

By combining mTLS enforcement with application-level validation and identity mapping, you reduce the risk of Broken Authentication. middleBrick’s scans can verify that these controls are present and that endpoints do not allow access when client certificates are missing or invalid.