Path Traversal in Aspnet with Mutual Tls

Path Traversal in ASP.NET occurs when an attacker manipulates file paths to access resources outside the intended directory, such as ../../../etc/passwd. Using Mutual TLS (mTLS) changes the threat surface but does not remove the underlying file path handling risks. In an mTLS-enabled ASP.NET application, the server authenticates the client via a client certificate, which can be used to enforce stricter access controls or to audit identity before processing file requests. However, if path parameters are derived from user input without proper validation, an authenticated client can still traverse directories.

For example, an endpoint like /files?name=report.pdf might concatenate the provided name with a base directory such as C:\inetpub\files\. If the application does not normalize and validate the resulting path, an attacker could supply report.pdf../../../secret/config.json and, despite presenting a valid client certificate, retrieve sensitive files. mTLS ensures the request is tied to a known identity, which may be logged and correlated to the attempted path traversal, but it does not sanitize the file path itself. Therefore, the combination of mTLS and path traversal leads to a scenario where access is authenticated yet the operation remains unsafe, potentially exposing configuration files, logs, or other sensitive data stored outside the application’s content root.

In the context of middleBrick scanning, endpoints that accept file or download parameters and use mTLS should be tested for path traversal by probing with encoded directory sequences and observing whether files outside the intended directory are returned. The scanner checks input validation and output handling across 12 security checks, including Property Authorization and Input Validation, which are relevant when mTLS is in use. Even with client certificates enforcing identity, insecure path handling can lead to data exposure, a finding that would be flagged with severity guidance and mapped to frameworks such as OWASP API Top 10 and PCI-DSS controls.

To remediate path traversal in ASP.NET while using Mutual TLS, apply strict path validation and avoid direct concatenation of user input into file system paths. Always resolve paths to ensure they remain within the intended directory, and use platform APIs that prevent directory escape.

Example: Secure file access with mTLS in ASP.NET Core

Below is a complete, syntactically correct example of an ASP.NET Core controller that requires client certificates and safely serves files from a designated folder.

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using System.IO;
using System.Linq;

[ApiController]
[Route("api/[controller]")]
public class FilesController : ControllerBase
{
    private readonly string _baseDirectory;

    public FilesController(IWebHostEnvironment env)
    {
        // Define a safe base directory, ideally configured via app settings
        _baseDirectory = Path.Combine(env.ContentRootPath, "wwwroot", "uploads");
        if (!Directory.Exists(_baseDirectory))
        {
            Directory.CreateDirectory(_baseDirectory);
        }
    }

    [HttpGet("{fileName}")]
    [Authorize]
    public IActionResult GetFile(string fileName)
    {
        // Validate input: allow only alphanumeric, dashes, underscores, and limited extensions
        if (string.IsNullOrWhiteSpace(fileName) ||
            !fileName.All(c => char.IsLetterOrDigit(c) || c == '.' || c == '-' || c == '_'))
        {
            return BadRequest("Invalid file name.");
        }

        // Build the full path and ensure it remains within _baseDirectory
        string fullPath = Path.GetFullPath(Path.Combine(_baseDirectory, fileName));
        if (!fullPath.StartsWith(_baseDirectory, StringComparison.OrdinalIgnoreCase))
        {
            return Forbid();
        }

        if (!System.IO.File.Exists(fullPath))
        {
            return NotFound();
        }

        var memory = new System.IO.MemoryStream(System.IO.File.ReadAllBytes(fullPath));
        return File(memory, "application/octet-stream", fileName);
    }
}

In this example, the application requires client certificates via ASP.NET Core’s authentication configuration. Ensure that Program.cs or Startup.cs enforces mTLS by setting the appropriate SslProtocols and client certificate mode. Here is a minimal configuration snippet for Program.cs:

var builder = WebApplication.CreateBuilder(args);

// Enforce HTTPS and client certificate authentication
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenAnyIP(5001, listenOptions =>
    {
        listenOptions.UseHttps(httpsOptions =>
        {
            httpsOptions.ClientCertificateMode = ClientCertificateMode.RequireCertificate;
            httpsOptions.SslProtocols = System.Security.Authentication.SslProtocols.Tls12 | System.Security.Authentication.SslProtocols.Tls13;
            // Certificate validation can be customized here if needed
        });
    });
});

builder.Services.AddAuthorization();
builder.Services.AddControllers();

var app = builder.Build();
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
app.Run();

Additionally, avoid using user input to determine subdirectories. If your application requires organizing files by user or category, map identifiers to safe directory names server-side rather than accepting them from the client. Combine these practices with the middleBrick CLI to scan endpoints using middlebrick scan <url> and review findings in the Web Dashboard to track security scores over time. The Pro plan supports continuous monitoring and can integrate with GitHub Actions to fail builds if risk scores degrade, helping maintain secure file handling even as the application evolves.