Insecure Deserialization in Aspnet with Mutual Tls

Insecure deserialization in ASP.NET applications occurs when untrusted data is used to manipulate object instantiation or execution flow. Even when mutual TLS (mTLS) is enforced to authenticate the client and server, mTLS does not prevent an attacker who has obtained a valid client certificate from sending malicious serialized payloads. mTLS secures the channel, but it does not validate the semantic safety of the data carried inside the request.

In practice, this vulnerability appears in endpoints that accept serialized objects via BinaryFormatter, SoapFormatter, or custom formatters without strict type constraints or integrity checks. For example, an ASP.NET Core Web API configured for mTLS may expose a POST endpoint like /api/report that deserializes incoming data using BinaryFormatter. If the endpoint trusts the client certificate but does not validate or sanitize the object graph, an attacker can craft a serialized payload that triggers remote code execution during deserialization, leading to arbitrary command execution on the server.

During a middleBrick scan, such endpoints are flagged under the Input Validation and Unsafe Consumption checks. The scanner detects dangerous deserialization patterns and references relevant attack vectors such as CVE-2020-1147 (Apache Commons Collections gadget chain) and CVE-2017-12149 (WebLogic WLS Core Components), which illustrate how gadget chains can be chained through deserialization to execute malicious code. Even with mTLS in place, if the application does not enforce strict type restrictions, allowlist-based deserialization, or digital signatures on serialized data, the attack surface remains open.

To detect this combination reliably, middleBrick runs the Unsafe Consumption check in parallel with other security checks, ensuring that insecure deserialization is identified regardless of transport-layer protections. The findings include severity ratings, contextual evidence, and remediation guidance that is mapped to frameworks such as OWASP API Security Top 10 and PCI-DSS requirements.

Securing ASP.NET applications with mutual TLS requires both proper transport configuration and secure handling of data at the application layer. Below are concrete code examples demonstrating how to enforce mTLS and safely handle deserialization.

Enabling Mutual TLS in ASP.NET Core

Configure Kestrel to require client certificates and validate them against a trusted Certificate Authority (CA). This ensures only authenticated clients can establish a connection.

// Program.cs (ASP.NET Core 6+)
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ServerCertificate = new X509Certificate2("server.pfx", "password");
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            httpsOptions.AllowedCipherSuites = new[]
            {
                TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
                TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
            };
            httpsOptions.ClientCertificateValidation = (cert, chain, errors) =>
            {
                // Additional custom validation can be added here
                return errors == SslPolicyErrors.None;
            };
        });
    });
});

var app = builder.Build();
app.MapGet("/", () => "Secure with mTLS");
app.Run();

Secure Deserialization Practices

Avoid BinaryFormatter for deserializing untrusted data. Use type-safe formats such as System.Text.Json with strict type constraints, or if you must use XML or JSON serialization, validate and restrict the allowed types.

// Safe deserialization with System.Text.Json
using System.Text.Json;

public class ReportRequest
{
    public string ReportId { get; set; }
    public string Format { get; set; }
}

app.MapPost("/api/report", (HttpRequest request) =>
{
    using var reader = new StreamReader(request.Body);
    string jsonBody = reader.ReadToEnd();

    var options = new JsonSerializerOptions
    {
        TypeInfoResolver = new DefaultJsonTypeInfoResolver
        {
            Modifiers = { context => context.TypeInfo.Type.GetProperties().ToList().ForEach(p => p.IsRequired = true) }
        }
    };

    try
    {
        var requestData = JsonSerializer.Deserialize<ReportRequest>(jsonBody, options);
        // Process requestData safely
        return Results.Ok(new { Message = "Report generated", Data = requestData });
    }
    catch (JsonException)
    {
        return Results.BadRequest("Invalid JSON format");
    }
});

Input Validation and Integrity Checks

When deserialization is unavoidable, use signed tokens or envelope encryption to ensure data integrity. Validate all inputs against an allowlist and avoid dynamically loading assemblies based on deserialized data.

// Example of validating input schema before processing
app.MapPost("/api/submit", (SubmitModel model) =>
{
    if (string.IsNullOrWhiteSpace(model.Type) || !new[] { "pdf", "csv" }.Contains(model.Type))
    {
        return Results.BadRequest("Invalid type specified");
    }

    // Proceed with safe processing
    return Results.Ok();
});

public class SubmitModel
{
    public string Type { get; set; }
    public string Content { get; set; }
}

By combining mTLS for transport security with strict deserialization controls, ASP.NET applications can reduce the risk of insecure deserialization attacks. middleBrick scans validate that these practices are in place and highlight gaps where attackers could exploit unsafe deserialization despite encrypted transport.