Sql Injection Blind in Aspnet

Blind SQL injection occurs when an application incorporates user input into a database query but does not return the query results directly to the attacker. In ASP.NET applications, this often manifests in scenarios where error messages are suppressed, output is filtered, or the application uses conditional logic based on query outcomes.

Common ASP.NET patterns include the use of SqlCommand or OleDbCommand objects with string concatenation for query construction. For example:

string userInput = Request.QueryString["id"];\nstring query = "SELECT * FROM Products WHERE ProductID = " + userInput;\nusing (SqlConnection conn = new SqlConnection(connString))\nusing (SqlCommand cmd = new SqlCommand(query, conn))\n{\n    cmd.ExecuteNonQuery();\n}\n

In this case, if userInput is not validated or parameterized, an attacker can inject conditions like 1=1 or 1=2 to test for query behavior. Because the application may not display database errors or results, the attacker relies on application-level responses such as changes in HTTP status codes, response timing, or subtle UI differences to infer whether the condition evaluated to true.

Another ASP.NET-specific vector involves data access layers built with DataSet or DataTable objects where dynamic filtering is applied without proper parameterization. For instance:

string filter = Request.QueryString["filter"];\nDataRow[] results = dataTable.Select("Name = '" + filter + "'");\n

If filter contains injected logic like ' OR '1'='1, the filter may return multiple rows, potentially altering application flow. Since the application may not expose raw query results, attackers can exploit timing differences or conditional rendering to enumerate data.

ASP.NET Web Forms and MVC applications are both susceptible, particularly when developers use inline SQL, dynamic LINQ expressions with user input, or third-party controls that build queries without sanitization. Even when using stored procedures, improper parameter binding or dynamic execution of procedure names can introduce blind injection risks.

Detecting blind SQL injection in ASP.NET applications requires monitoring for anomalous behavior in request handling and response patterns. middleBrick performs black-box scanning by sending crafted payloads to API endpoints and analyzing behavioral responses without requiring authentication or credentials.

For example, middleBrick may send requests with payloads like ' OR '1'='1, ' OR '1'='2, or %' WAITFOR DELAY '00:00:05'-- to detect time-based blind conditions. If the application responds differently — such as delayed responses, changes in HTTP status codes, or variations in DOM structure — middleBrick flags this as a potential blind SQL injection vector.

During scanning, middleBrick checks for:

• Use of dynamic query construction in ASP.NET Web Forms pages or MVC controllers
• Improper handling of query parameters in SqlCommand, OleDbCommand, or LINQ-to-SQL expressions
• Error suppression in custom error pages that prevent exposure of database messages
• Conditional rendering based on query outcomes, such as row count checks

The scanner also evaluates API specifications (OpenAPI/Swagger) for query parameter definitions that accept unvalidated input, particularly when $ref schemas lack type constraints or validation rules. This allows middleBrick to prioritize endpoints where blind injection is more likely.

Findings are categorized under the OWASP API Top 10 classification A03:2023 - Injection, with specific mapping to Injection and subcategories for SQL Injection. The scanner provides severity ratings (e.g., High) and remediation guidance aligned with ASP.NET best practices.

Remediation of blind SQL injection in ASP.NET applications centers on eliminating unsafe string concatenation in data access code and enforcing parameterized queries. The primary defense is the use of SqlParameter objects with SqlCommand, which separates code logic from data input.

For example, the vulnerable code:

string userInput = Request.QueryString["id"];\nstring query = "SELECT * FROM Products WHERE ProductID = " + userInput;\n

Should be replaced with:

string userInput = Request.QueryString["id"];\nusing (SqlConnection conn = new SqlConnection(connString))\nusing (SqlCommand cmd = new SqlCommand("SELECT * FROM Products WHERE ProductID = @id", conn))\n{\n    cmd.Parameters.Add("@id", SqlDbType.VarChar).Value = userInput;\n    conn.Open();\n    cmd.ExecuteNonQuery();\n}\n

This approach prevents input from being interpreted as SQL syntax, neutralizing injection attempts.

For applications using LINQ or Entity Framework, developers should avoid dynamic expression building with untrusted input. Instead, use strongly typed queries. For example:

var id = int.Parse(Request.QueryString["id"]);\nvar product = context.Products.SingleOrDefault(p => p.Id == id);\n

If dynamic filtering is necessary, use Expression> with validated input or employ a whitelist of allowed field names.

Additionally, ASP.NET applications should configure customErrors appropriately to avoid leaking internal details, but this should not replace input validation. Instead, combine proper error handling with input sanitization and parameterization.

ASP.NET validators like RegexAttribute or custom model binders can help enforce input structure, but they are not sufficient alone. The safest practice is to treat all user input as untrusted and use parameterized data access patterns exclusively.