Injection Flaws in Aspnet (Csharp)

Injection flaws occur when an application sends untrusted data to an interpreter as part of a command or query. In ASP.NET with C#, this most commonly manifests as SQL injection, but can also appear in command injection, LDAP injection, or expression injection when dynamic evaluation is used. The combination of ASP.NET’s runtime pipeline and C#’s type system can inadvertently expose injection risks when developers concatenate user input into strings that are later interpreted by a parser or database engine.

Consider a typical pattern in an ASP.NET Core controller that builds a SQL query using string concatenation:

// Risky: string concatenation used to build SQL
var sql = $"SELECT * FROM Users WHERE Username = '{username}' AND Role = '{role}'";
using var command = new SqlCommand(sql, connection);
var reader = command.ExecuteReader();

Here, username and role are untrusted inputs. Even with C#’s static typing, if these values contain SQL metacharacters (e.g., ' OR 1=1 --), the resulting command can bypass authentication or extract data. ASP.NET’s model binding does not automatically sanitize inputs for SQL; it only maps JSON or form data to C# objects. This means developers must explicitly parameterize queries.

Another scenario involves command injection when invoking system processes from C# code in an ASP.NET context:

var userInput = Request.Query["filename"];
var process = new Process();
process.StartInfo.FileName = "ffmpeg";
process.StartInfo.Arguments = $"-i {userInput} output.mp4";
process.Start();

If userInput includes shell metacharacters (e.g., ; rm -rf /), the system may execute unintended commands. C# does not inherently escape shell arguments, so the onus is on the developer to avoid concatenation and use safe APIs.

Expression injection can occur when using libraries that evaluate strings as code, such as dynamic LINQ or script engines. For example:

var filter = Request.Query["filter"];
var query = db.Users.Where(filter); // If filter is user-supplied

If filter contains malicious expressions like "1 == 1; Delete From Users", the runtime may interpret it unsafely, depending on the library. C#’s type system does not prevent this because the expression is parsed at runtime by an external evaluator.

These patterns highlight that injection flaws in ASP.NET with C# arise not from the language itself, but from insecure handling of untrusted data. The OWASP API Top 10 lists injection as a common risk, and real-world CVEs (e.g., CVE-2021-42013 in Apache Struts, which involves OGNL injection) demonstrate the impact when input is improperly concatenated into execution contexts. ASP.NET applications must treat all inputs as hostile and apply context-specific escaping or parameterization.

Remediation centers on avoiding string concatenation for commands and queries, using language features and libraries that enforce safety. For SQL access in ASP.NET, always use parameterized queries with SqlCommand or an ORM that supports parameterization, such as Entity Framework Core.

// Safe: parameterized query
var sql = "SELECT * FROM Users WHERE Username = @username AND Role = @role";
using var command = new SqlCommand(sql, connection);
command.Parameters.AddWithValue("@username", username);
command.Parameters.AddWithValue("@role", role);
var reader = command.ExecuteReader();

The parameters are passed separately from the command text, ensuring that user input is never interpreted as SQL syntax. This approach works consistently across ADO.NET and higher-level abstractions.

For process invocation, avoid passing user input directly to shell commands. Instead, use the ProcessStartInfo constructor that does not invoke a shell, and validate input against a strict allowlist:

var allowedFiles = new HashSet<string> { "video1.mp4", "video2.mp4" };
var userInput = Request.Query["filename"];

if (!allowedFiles.Contains(userInput))
{
    throw new ArgumentException("Invalid file");
}

var process = new Process();
process.StartInfo.FileName = "ffmpeg";
process.StartInfo.Arguments = $"-i {userInput} output.mp4"; // Still risky; prefer file path APIs
process.Start();

A safer approach is to use file system APIs to move or transform files without invoking a shell. If a shell is unavoidable, use argument escaping libraries or platform-specific APIs (e.g., System.Security.SecurityElement.Escape for XML contexts, though not for shell).

For dynamic query composition (e.g., LINQ), prefer expression trees or compiled predicates instead of string-based filters. If dynamic filtering is required, use a parser with strict grammar rules and avoid eval-like constructs. For example, with LINQ:

// Safe: using expression trees
var parameter = Expression.Parameter(typeof(User), "u");
var property = Expression.Property(parameter, "Role");
var constant = Expression.Constant("Admin");
var equality = Expression.Equal(property, constant);
var lambda = Expression.Lambda<Func<User, bool>>(equality, parameter);
var query = db.Users.Where(lambda);

This ensures that the structure of the query is built programmatically, not from raw strings. MiddleBrick scans can help detect injection risks in your API endpoints, and the Pro plan allows you to integrate these checks into CI/CD pipelines to catch such issues before deployment.