Training Data Extraction in Aspnet (Csharp)

Training data extraction in ASP.NET applications written in Csharp occurs when an attacker causes the application to disclose sensitive information that was used to train models, stored in configuration, or embedded in source code. Because ASP.NET applications often manage datasets for machine learning preprocessing, logging, or dynamic model selection, careless handling of data paths, serialization, and error messages can leak records that should remain private.

In Csharp, common patterns such as reading files with System.IO.File.ReadAllText, deserializing JSON with System.Text.Json, or constructing dynamic LINQ queries can inadvertently expose training datasets if input validation is weak. For example, an endpoint that accepts a model identifier and loads a file from disk without sanitizing the parameter may allow path traversal (e.g., ../../../training-data.json), returning raw training samples to the attacker. Similarly, verbose exception messages in Csharp stack traces can reveal directory structures, connection strings, or sample data snippets when exceptions are not properly abstracted.

ASP.NET middleware and model-binding pipelines can amplify these risks. If model-binding pulls raw request data into Csharp objects used for training, insufficient validation may let an attacker inject crafted payloads that cause the application to read or return training corpora. Serialization settings that include type information (e.g., JsonSerializerOptions.IncludeFields or TypeNameHandling) can expose internal data structures, inadvertently revealing how training data is organized. Attack patterns such as insecure deserialization (related to CVE-2020-36329) are relevant when Csharp applications deserialize untrusted input used to select or filter training datasets.

The framework’s default behavior can also contribute. For instance, serving static files from a folder that contains CSV or Parquet training artifacts without proper restrictions may allow direct download. In Csharp, misconfigured IStaticFileOptions or missing authorization on controller actions can expose these endpoints. Logging mechanisms that capture request payloads for debugging purposes might store sensitive training examples if log levels are set too verbosely and retention policies are weak.

middleBrick scans such surfaces in unauthenticated mode, identifying paths where training data may be extracted through insecure file handling, insufficient input validation, or overly informative errors. The scanner checks for information exposure risks across the API surface and maps findings to frameworks like OWASP API Top 10 and GDPR, highlighting the need to isolate training data from unauthenticated endpoints. In environments using LLMs, the LLM/AI Security checks specifically probe for system prompt leakage and output exposure that could reveal training data patterns, ensuring AI-specific risks are surfaced alongside traditional API concerns.

To mitigate training data extraction in ASP.NET applications written in Csharp, apply strict input validation, avoid exposing internal paths, and secure file access patterns. Use parameterized paths, enforce allowlists for model identifiers, and ensure exceptions do not leak sensitive context.

1. Validate and sanitize model identifiers

Never trust user-supplied identifiers that influence file paths. Use an allowlist and map identifiers to safe locations.

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

[ApiController]
[Route("api/[controller]")]
public class ModelController : ControllerBase
{
    private static readonly Dictionary<string, string> AllowedModels = new()
    {
        ["fraud-v1"] = "models/fraud-v1.json",
        ["sentiment-lite"] = "models/sentiment-lite.json"
    };

    [HttpGet("{modelName}")]
    public IActionResult GetModel(string modelName)
    {
        if (!AllowedModels.TryGetValue(modelName, out var filePath))
        {
            return BadRequest("Invalid model name");
        }

        var fullPath = Path.GetFullPath(filePath);
        // Ensure resolved path remains within allowed directory
        var baseDir = Path.GetFullPath("./models");
        if (!fullPath.StartsWith(baseDir, StringComparison.Ordinal))
        {
            return StatusCode(500, "Configuration error");
        }

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

        var json = System.IO.File.ReadAllText(fullPath);
        return Content(json, "application/json");
    }
}

2. Secure exception handling to avoid data leakage

Use a centralized exception handler that strips stack traces and avoids exposing paths or configuration details.

using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();
var app = builder.Build();

app.UseExceptionHandler(appError =>
{
    appError.Run(async context =>
    {
        context.Response.StatusCode = 500;
        await context.Response.WriteAsJsonAsync(new { error = "Internal server error" });
    });
});

app.Run();

3. Restrict static file exposure

Do not serve directories that contain training artifacts unless explicitly required, and limit file types.

app.UseStaticFiles(new StaticFileOptions
{
    FileProvider = new PhysicalFileProvider(
        Path.Combine(Directory.GetCurrentDirectory(), "wwwroot")),
    RequestPath = "/static",
    ContentTypeProvider = new FileExtensionContentTypeProvider
    {
        Mappings = { [".txt"] = "text/plain" }
    }
});

4. Harden deserialization settings

Avoid including type metadata and prefer schema-bound models for data exchange.

var options = new JsonSerializerOptions
{
    PropertyNameCaseInsensitive = true,
    // Do not include TypeInfo; avoid TypeNameHandling
};
var model = JsonSerializer.Deserialize<MyDataModel>(json, options);

5. Redact sensitive values in logs

Configure logging filters to exclude training data samples and secrets from output.

// In Program.cs or appsettings.json
builder.Logging.AddFilter("Microsoft.AspNetCore.DataProtection", LogLevel.Warning);
builder.Logging.AddFilter("System.Net.Http.HttpClient", LogLevel.Warning);

By combining these Csharp-specific practices with continuous scanning using tools such as middleBrick, teams can detect insecure file handling and information exposure early. The CLI (middlebrick scan <url>) and GitHub Action can be integrated to validate that remediation does not reintroduce risks, while the dashboard enables tracking of security scores over time.