Formula Injection in Aspnet with Cockroachdb

Formula Injection occurs when user-controlled data is interpreted as part of a query or command rather than as literal values. In an ASP.NET application using CockroachDB, this typically manifests through dynamic SQL construction where input is concatenated into statements instead of being passed as parameters. CockroachDB, while PostgreSQL-wire compatible, enforces strict SQL semantics and does not tolerate ambiguous or unsafe interpolation the way some embedded databases might.

Consider an endpoint in ASP.NET that retrieves a user profile by username. If the developer builds the query by string concatenation, an attacker can inject a formula-like payload such as ' OR '1'='1 to alter the logic. Because CockroachDB adheres to SQL standards, the injected formula is parsed as valid SQL, potentially bypassing authentication or exposing other users’ data.

In more complex scenarios, injection can target computed fields or conditional logic. For example, an ASP.NET Core controller might construct an ORDER BY clause dynamically using user input. If the input is not validated, an attacker can supply a payload like 1; SELECT * FROM secrets. CockroachDB will execute the statement as written if the application does not enforce strict parameterization, leading to data exfiltration through secondary result sets or error-based extraction.

The risk is amplified when the application uses dynamic SQL inside stored procedures or application-level query builders that still rely on string interpolation. CockroachDB’s parser will process the injected formula exactly as it would a legitimate clause, meaning there is no syntactic guard to reject malicious logic if the input reaches the database layer unchecked.

Additionally, if the ASP.NET application exposes an unauthenticated endpoint that queries CockroachDB with user-supplied filters, an attacker can probe for injection using payloads that reference system tables or inject boolean logic. Because the scan testing methodology of middleBrick evaluates unauthenticated attack surfaces, such endpoints are automatically tested for formula injection patterns against CockroachDB responses to detect deviations indicative of successful injection.

To contextualize the impact, formula injection in this stack maps to the OWASP API Top 10 category of Injection and can lead to bypassing authentication, unauthorized data access, or secondary statement execution. MiddleBrick’s checks for this vulnerability include validating that responses differ based on injected formulas when authentication is absent, confirming whether the endpoint improperly interprets user input as executable logic.

Remediation centers on strict parameterization and avoiding string concatenation for SQL construction. In ASP.NET, use typed parameters with ADO.NET or an ORM that supports placeholders. Never interpolate user input directly into SQL strings, even when interacting with CockroachDB’s PostgreSQL compatibility layer.

Example of vulnerable code using string concatenation:

// Vulnerable: string concatenation with user input
var username = req.Query["username"];
var sql = $"SELECT id, email FROM users WHERE username = '{username}'";
using var cmd = new NpgsqlCommand(sql, connection);
using var reader = cmd.ExecuteReader();

Exploitable payload: username=admin'-- can bypass intended filtering. The injected formula changes the query intent, and CockroachDB executes the modified statement.

Secure implementation using parameters:

// Secure: parameterized query with NpgsqlCommand
var username = req.Query["username"];
using var cmd = new NpgsqlCommand("SELECT id, email FROM users WHERE username = @username", connection);
cmd.Parameters.AddWithValue("@username", username);
using var reader = cmd.ExecuteReader();

When using Entity Framework Core with CockroachDB, apply the same principle. Do not use raw SQL with interpolation. Instead, rely on LINQ or parameterized raw SQL methods:

// Secure with Entity Framework Core using parameterized raw SQL
var username = req.Query["username"];
var user = await context.Users
    .FromSqlRaw("SELECT * FROM users WHERE username = {0}", username)
    .FirstOrDefaultAsync();

For dynamic sorting, avoid passing column names directly from user input. If dynamic ordering is required, map input to a whitelist of allowed columns:

// Secure: whitelist-based dynamic ordering
var order = req.Query["order"];
string[] allowedColumns = { "created_at", "email", "username" };
var column = allowedColumns.Contains(order) ? order : "created_at";
using var cmd = new NpgsqlCommand($"SELECT id, email FROM users ORDER BY {column} ASC", connection);
// Note: column name interpolation is safe here because it is derived from a strict whitelist, not user-supplied arbitrary input.

Input validation should complement parameterization. Reject inputs that contain SQL meta-characters or keywords when they are not expected. For CockroachDB, ensure that the application layer normalizes and sanitizes based on the expected data format, such as enforcing alphanumeric usernames with a regex pattern before the value reaches any SQL builder.

middleBrick scans validate these protections by submitting formula injection probes and checking whether CockroachDB responses reflect altered logic. The tool cross-references findings with the OpenAPI spec to confirm whether dynamic SQL usage is documented and whether parameterization is correctly declared in the API contract.

Using the middleBrick CLI, developers can test their endpoints with middlebrick scan <url> to receive a security score and prioritized findings, including formula injection risks specific to their CockroachDB-backed ASP.NET services. The Pro plan enables continuous monitoring so that any regression in parameterization is flagged before deployment.