Sql Injection in Fiber with Basic Auth

SQL Injection in a Fiber application that uses HTTP Basic Authentication can occur when user-controlled input is concatenated into SQL queries, even when authentication credentials are validated first. Basic Auth supplies a username and password in an Authorization header; these values are often decoded and then passed into business logic that interacts with a database. If the developer uses those credentials to build dynamic SQL—such as string interpolation or concatenation—attackers can supply crafted credentials that modify query structure.

For example, consider a login route that decodes Basic Auth and directly interpolates the username into a query. An attacker can send an Authorization header like dXNlcjogJ1x1YmFja3dvcmQ6JyAnICsgJzwnICsgJyk= (decoded: user: ' OR '1'='1). If the application builds SQL as SELECT * FROM users WHERE username = 'USER' AND password = '...', the injected payload changes the logic to always return true, bypassing password checks and potentially extracting or modifying data. This pattern is relevant to the Authentication and BOLA/IDOR checks in middleBrick’s 12 security checks, where malformed or malicious credentials are tested to detect insecure query construction.

Even when authentication succeeds, SQL Injection remains possible in endpoints that accept additional path or query parameters after authentication. For instance, an authenticated request to /users/{id} might use the authenticated username in logging and then use an untrusted ID parameter to fetch records. If the ID is concatenated into SQL, attackers can leverage secondary injection techniques, especially if the database supports stacked queries or if error messages leak table structures. middleBrick’s Input Validation and Data Exposure checks help surface these risks by observing how the endpoint behaves with malformed input and whether sensitive data is returned in error responses.

Other contributing factors include improper schema design and verbose error handling, which make exploitation easier. Developers may assume that Basic Auth protects the endpoint, but once authentication passes, unsafe query building re-introduces risk. Using parameterized queries or prepared statements ensures that attacker-supplied values are treated strictly as data, not executable SQL. middleBrick’s scans test these scenarios without credentials, focusing on the unauthenticated attack surface and highlighting where input handling fails to isolate SQL control characters.

Remediation centers on never mixing authentication-derived or user-controlled values into raw SQL strings. Use parameterized queries or prepared statements, validate and normalize inputs, and avoid including credentials in SQL logic. Below are concrete Fiber examples in Go that demonstrate insecure patterns and their secure counterparts.

Insecure example with string interpolation:

// UNSAFE: concatenating user input into SQL
username := getBasicAuthUsername(c)
var users []User
database.Raw("SELECT id, username FROM users WHERE username = '" + username + "'").Scan(&users)

Secure example using parameterized queries:

// SAFE: using placeholders to separate SQL logic from data
username := getBasicAuthUsername(c)
var users []User
if err := database.Where("username = ?", username).Find(&users).Error; err != nil {
    // handle error
}

If you must construct dynamic queries, use named parameters or a query builder that enforces parameterization:

// SAFE: using named parameters with sql.Named
query := `SELECT id, username FROM users WHERE username = :username AND status = :status`
args := sql.Named("username", username)
args = append(args, sql.Named("status", "active"))
database.Raw(query, args...).Scan(&users)

Additionally, sanitize and validate the Basic Auth username before use. For example, enforce allowed characters and length limits to reduce injection surface:

// Validate username format before using it in a query
if !regexp.MustCompile(`^[A-Za-z0-9._-]{3,64}$`).MatchString(username) {
    c.Status(fiber.StatusBadRequest)
    return c.JSON(fiber.Map{"error": "invalid username format"})
}

Logging and error handling should avoid echoing raw user input or SQL errors to clients. Use structured logging that references request IDs rather than raw credentials, and return generic error messages to prevent information leakage that could aid in crafting injection payloads.