Sql Injection Union in Actix

In Actix web applications, SQL injection via UNION occurs when user input is concatenated directly into SQL queries without proper parameterization, allowing attackers to append UNION SELECT statements to extract arbitrary data. This commonly appears in Actix handlers that extract query parameters or path segments and pass them raw to database clients like sqlx or deadpool-postgres. For example, a search endpoint might accept a category parameter and build a query like "SELECT * FROM products WHERE category = '" + category + '". If an attacker supplies ' UNION SELECT username, password FROM users--, the resulting query becomes SELECT * FROM products WHERE category = '' UNION SELECT username, password FROM users--', which returns user credentials alongside product data. Actix's async handler structure does not inherently prevent this; the vulnerability lies in the data access layer. The UNION technique is particularly effective in Actix because the framework's JSON or form extractors (e.g., web::Query, web::Path) make it easy to access user input, which developers then mistakenly treat as safe for SQL construction. Real-world equivalents include CVE-2021-42574 in Apache Apereo CAS, where UNION-based injection allowed authentication bypass via crafted service parameters, demonstrating how input trusted in web frameworks can lead to critical data exposure when not isolated from query builders.

Detecting SQL injection UNION in Actix requires observing how user input flows into SQL statements during black-box scanning, as source code review isn't feasible in a self-service model. middleBrick identifies this by sending payloads designed to trigger UNION-based responses, such as ' UNION SELECT NULL, table_name FROM information_schema.tables-- or ' UNION SELECT 1,@@version,3--, and analyzing responses for anomalies like unexpected data rows, error messages revealing database structure, or changes in response length/status code. In Actix contexts, scanners target endpoints that reflect input in responses—like search, filter, or lookup handlers—where UNION injection often leaks data through the same channel as legitimate results. For instance, if a /items?name= endpoint normally returns JSON arrays of item names, injecting ' UNION SELECT secret_column FROM sensitive_table-- might return JSON containing secrets. middleBrick's parallel checks include Input Validation and Data Exposure categories, which correlate anomalous responses with injection patterns. The scanner does not inspect Actix internals but focuses on HTTP behavior: a successful UNION injection may yield 200 OK with extra fields in JSON or visible data in HTML tables, differentiating it from benign errors. This approach aligns with OWASP API Top 10 2023: API3:2023 Broken Object Property Authorization, where improper input handling enables property-level data access via injection.

Fixing SQL injection UNION in Actix applications requires eliminating string concatenation in SQL queries and using parameterized queries via Actix-compatible database libraries. The core principle is separating code from data: never embed user input directly into SQL strings. With sqlx, the recommended approach for Actix is to use query macros or query_as! with placeholders. For example, instead of:
let query = format!("SELECT * FROM items WHERE name = '{}'", name);
use:
let item = sqlx::query_as!(Item, "SELECT * FROM items WHERE name = $1", name)
.fetch_one(&pool)
.await?;
Here, $1 is a positional parameter that sqlx safely escapes, preventing UNION injection. For dynamic queries (e.g., optional filters), use sqlx::query! with conditional clause building but always parameterize values:
let mut query = sqlx::query("SELECT * FROM items WHERE 1=1");
if let Some(name) = name_filter {
query = query.bind(name);
query.push(" AND name = $");
// Note: Actual implementation uses bind() and tracks index
}
let items = query.fetch_all(&pool).await?;
This ensures all user input is treated as data, not executable SQL. Actix's extractors (web::Query, web::Path) remain safe to use—they only parse input; the vulnerability arises in how that input is used. Remediation also involves validating input against allowlists (e.g., restricting category to known values) as a defense-in-depth measure, but parameterization is the primary fix. middleBrick provides remediation guidance in reports, pointing developers to library-specific safe patterns without mandating tool changes.