Log Injection in Aspnet with Cockroachdb

Log injection occurs when untrusted data is written directly into application logs without proper validation or encoding. In an ASP.NET application that uses CockroachDB as the backend database, the combination of dynamic request data, structured logging practices, and CockroachDB’s SQL interface can expose log injection risks if developer input is concatenated into log messages or query metadata without sanitization.

ASP.NET typically logs incoming requests, controller actions, and database interaction details for observability. When the application builds log entries by interpolating user-supplied values (e.g., identifiers, query parameters, or form fields) directly into strings that are later written to logs, malicious actors can inject newlines, structured log delimiters, or false metadata. CockroachDB does not introduce log injection by itself, but its usage in ASP.NET often involves constructing log context around SQL operations—such as query text, parameter values, or transaction IDs—if these values are not sanitized, the logs can be polluted.

Consider an endpoint that fetches a tenant record by an identifier provided in the request. If the logging code includes the raw identifier in the log message, an attacker can supply a value containing carriage returns or structured log syntax (e.g., JSON key delimiters), causing log parsers to misinterpret log boundaries or inject false entries. In distributed tracing or structured logging setups (e.g., using Serilog with sinks that enrich events with SQL-related properties), unsanitized CockroachDB query metadata—such as table names or condition values—can similarly be leveraged to distort log integrity.

Real-world attack patterns include newline injection to separate log entries, tag injection to override log context fields, and injection of executable content when logs are later processed by visualization tools that render content in dashboards. While this does not directly enable SQL execution within CockroachDB, it undermines log reliability, complicates incident investigation, and may facilitate secondary attacks if logs are used as an audit source for compliance (e.g., PCI-DSS, SOC2).

middleBrick scans such ASP.NET + CockroachDB integrations for log injection risks among its 12 checks, including input validation and unsafe consumption patterns, ensuring that log construction does not expose the attack surface. The scanner does not fix the code but provides prioritized findings with remediation guidance to help developers sanitize inputs and structure logs safely.

To mitigate log injection when working with CockroachDB in ASP.NET, you should treat all dynamic content used in logging as untrusted. This includes request identifiers, parameter values, and any metadata derived from SQL operations. Use structured logging with strongly typed objects instead of string concatenation, and ensure that values written to logs are escaped or encoded appropriately.

Below are concrete remediation examples using CockroachDB with parameterized queries and safe logging patterns in ASP.NET.

1. Use Parameterized Queries and Log Only Safe Metadata

Always use parameterized queries to separate SQL logic from data, and log only sanitized metadata.

// Example using Npgsql with CockroachDB in ASP.NET
using var conn = new NpgsqlConnection("Host=my-cockroachdb-host;Database=mydb;Username=myuser;Password=mypass");
await conn.OpenAsync();

// Safe parameterized query
var sql = "SELECT id, name FROM tenants WHERE id = @id";
using var cmd = new NpgsqlCommand(sql, conn);
cmd.Parameters.AddWithValue("id", tenantId);

using var reader = await cmd.ExecuteReaderAsync();
while (await reader.ReadAsync())
{
    // Log only sanitized, non-user-controlled metadata
    _logger.LogInformation("Tenant fetched: {TenantId}", reader.GetGuid("id"));
}

2. Sanitize Inputs Before Logging

If you must log user input, sanitize newlines and delimiters to prevent injection into log streams.

private string SanitizeForLog(string input)
{
    if (string.IsNullOrEmpty(input)) return input;
    // Remove newlines and carriage returns that can break log structure
    return input.Replace("\r", "\\r").Replace("\n", "\\n").Trim();
}

// Usage in a controller
public async Task GetTenant(Guid id)
{
    var safeId = SanitizeForLog(id.ToString());
    _logger.LogInformation("Processing request for tenant ID: {SafeId}", safeId);

    // Proceed with CockroachDB call using parameterized query as above
}

3. Enrich Structured Logs with Explicit Field Mapping

When using structured logging frameworks (e.g., Serilog), map CockroachDB-related fields explicitly to avoid parser misinterpretation.

// In Program.cs or logging configuration
Log.Logger = new LoggerConfiguration()
    .WriteTo.Console()
    .Enrich.WithProperty("DbType", "CockroachDB")
    .CreateLogger();

// In a service
_logger.LogInformation("SQL query completed", new
{
    QueryType = "SelectTenant",
    Table = "tenants",
    // Avoid embedding raw SQL text with user input
    Status = "Success"
});

4. Avoid Logging Raw SQL Text with Embedded Values

Do not log concatenated SQL strings that include user-controlled values. Instead, log query intent and parameterized summaries.

// Avoid this:
// _logger.LogInformation($"Executing SELECT * FROM tenants WHERE id = '{userInput}'");

// Prefer this:
_logger.LogDebug("Executing parameterized tenant query");
// Use the parameterized command as shown earlier

By combining these practices—parameterized queries, input sanitization, and disciplined structured logging—you reduce the risk of log injection while maintaining visibility into CockroachDB interactions within ASP.NET. middleBrick’s checks support this posture by flagging unsafe logging patterns and input validation gaps.