Sql Injection Union in Aspnet (Csharp)

SQL Injection via UNION-based techniques in an ASP.NET application using C# occurs when user-controlled input is concatenated into SQL strings without proper validation or parameterization, and the attacker leverages the UNION operator to append additional queries. In C#, this typically manifests in ADO.NET code where string interpolation or concatenation builds dynamic SQL, for example using string query = $"SELECT * FROM Users WHERE Username = '{username}' AND Role = '{role}'";. If the developer then appends a UNION clause based on unchecked input, such as query += " UNION SELECT id, name, password FROM Users--";, the attacker can manipulate the username or other parameters to inject this payload. The risk is compounded when the application uses string building instead of parameterized queries, as the .NET runtime does not inherently sanitize inputs. Because the scan endpoint provided to middleBrick is unauthenticated, it can probe these injection surfaces by submitting crafted payloads like ' UNION SELECT null, null, @@version-- and observing differences in responses, such as data leaks or malformed errors. This technique maps to the OWASP API Top 10 A03:2021 — Injection, and real-world advisories such as CVE-2023-24530 describe similar UNION-based SQL injection in web APIs where input is reflected in database responses. In the context of middleBrick’s 12 security checks, the scanner tests input validation and data exposure categories by attempting to infer schema details through UNION-based extraction, which can expose sensitive columns or trigger excessive data disclosure. Since ASP.NET applications often rely on dynamic SQL for flexibility, developers must ensure strict use of parameterized commands to prevent these paths from being reachable.

To remediate SQL Injection UNION attacks in ASP.NET with C#, replace string concatenation with parameterized queries using SqlCommand and SqlParameter. This ensures that user input is treated strictly as data, not executable SQL. Below is a secure example using ADO.NET:

using System.Data.SqlClient;

public User GetUser(string username, string role)
{
    using var connection = new SqlConnection(Configuration.GetConnectionString("DefaultConnection"));
    connection.Open();
    const string query = "SELECT Id, Name, Role FROM Users WHERE Username = @username AND Role = @role";
    using var command = new SqlCommand(query, connection);
    command.Parameters.AddWithValue("@username", username);
    command.Parameters.AddWithValue("@role", role);
    using var reader = command.ExecuteReader();
    if (reader.Read())
    {
        return new User
        {
            Id = reader.GetInt32(0),
            Name = reader.GetString(1),
            Role = reader.GetString(2)
        };
    }
    return null;
}

If using Entity Framework Core, leverage LINQ or FromSqlRaw with parameters instead of raw string concatenation:

var user = context.Users
    .FromSqlRaw("SELECT * FROM Users WHERE Username = {0} AND Role = {1}", username, role)
    .FirstOrDefault();

Additionally, enforce input validation using ASP.NET Core model binding and data annotations to reject unexpected formats before they reach data access layers. middleBrick’s checks for input validation and property authorization can help confirm these controls are effective. For continuous assurance, use the CLI tool to scan from terminal with middlebrick scan <url> or integrate the GitHub Action to add API security checks to your CI/CD pipeline, failing builds if risk scores drop below your chosen threshold. Teams on the Pro plan can enable continuous monitoring to run scans on a configurable schedule and receive alerts via Slack or Teams, while the Web Dashboard lets track your API security scores over time.