Sql Injection in Gorilla Mux with Hmac Signatures

Gorilla Mux is a widely used HTTP router for Go that enables expressive route matching through path variables and query parameters. When HMAC signatures are introduced to authenticate requests, developers may assume the request is tamper-proof. However, if input validation and SQL construction are not handled securely, the combination can still lead to SQL Injection despite the presence of HMAC-based integrity checks.

HMAC signatures ensure that the payload has not been altered in transit, but they do not validate the safety of the data used in SQL queries. For example, a client may sign a JSON body containing a user identifier, and the server may trust the signature while directly interpolating the identifier into a raw SQL string. This pattern violates secure coding practices and can enable an attacker who knows or guesses a valid HMAC key to craft payloads that inject malicious SQL via trusted parameters.

Consider a route like /user/{id} where the client sends an HMAC-signed token in a header (e.g., X-API-Signature). If the server verifies the signature and then uses the id path variable in a query such as SELECT * FROM users WHERE id = ' + id + ', the application remains vulnerable. Gorilla Mux provides the variables, but the developer’s handling of those variables determines safety. Attackers may probe endpoints with crafted IDs (e.g., 1 OR 1=1--) to test whether the input is sanitized. Even with HMAC in place, if the server fails to use parameterized queries, the signature verification becomes an insufficient safeguard.

Additionally, query parameters and HTTP headers included in the HMAC calculation can still be sources of injection if concatenated into SQL strings. For instance, a signed query filter such as email from a JSON body could allow an attacker to inject SQL via carefully crafted input that passes signature verification but breaks query logic. The presence of HMAC does not mitigate risks like missing type checks, lack of allowlists, or improper escaping, which remain common causes of SQL Injection in Go web services.

Real-world attack patterns include attempts to bypass authentication by injecting SQL into searchable fields, or to extract data via error-based techniques. These can map to OWASP API Top 10 A03:2023 — Injection, and may also intersect with BOLA/IDOR if the injected SQL changes the authorization context. Using parameterized queries and strict input validation remains essential even when HMAC signatures are employed to protect request integrity.

Remediation focuses on ensuring that all data used in SQL statements is properly parameterized and validated, regardless of HMAC verification. HMAC should be treated as a mechanism for integrity, not safety of content. Below are concrete examples demonstrating secure handling in Gorilla Mux.

First, use prepared statements with placeholders instead of string concatenation. This ensures that user-supplied values are never directly interpolated into SQL.

import (
    "database/sql"
    "net/http"
    "github.com/gorilla/mux"
)

func getUserHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        vars := mux.Vars(r)
        id := vars["id"]

        var name string
        // Use parameterized query to prevent SQL Injection
        err := db.QueryRow("SELECT name FROM users WHERE id = $1", id).Scan(&name)
        if err != nil {
            http.Error(w, "User not found", http.StatusNotFound)
            return
        }
        w.Write([]byte("Name: " + name))
    }
}

Second, validate and sanitize inputs before including them in the HMAC calculation and before using them in queries. Apply allowlists where possible, such as ensuring IDs are numeric.

func validateID(id string) bool {
    // Allowlist: only digits
    for _, ch := range id {
        if ch < '0' || ch > '9' {
            return false
        }
    }
    return true
}

func secureGetUser(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        vars := mux.Vars(r)
        id := vars["id"]

        if !validateID(id) {
            http.Error(w, "Invalid ID", http.StatusBadRequest)
            return
        }

        var email string
        err := db.QueryRow("SELECT email FROM profiles WHERE user_id = $1", id).Scan(&email)
        if err != nil {
            http.Error(w, "Profile not found", http.StatusNotFound)
            return
        }
        w.Write([]byte("Email: " + email))
    }
}

Third, ensure that any data influencing SQL construction—such as query parameters or headers included in the HMAC—is handled safely. Do not rely on the signature alone to prevent injection; always treat external inputs as untrusted.

func verifyAndUse(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // Assume HMAC verification happens earlier and sets r.Context() values
        userID := r.Context().Value("userID")
        id, ok := userID.(string)
        if !ok || !validateID(id) {
            http.Error(w, "Unauthorized or invalid", http.StatusUnauthorized)
            return
        }

        var username string
        // Safe parameterized query
        err := db.QueryRow("SELECT username FROM accounts WHERE id = $1", id).Scan(&username)
        if err != nil {
            http.Error(w, "Access denied", http.StatusForbidden)
            return
        }
        w.Write([]byte("Welcome " + username)) 
    }
}

These examples emphasize that HMAC signatures protect message integrity, but SQL safety requires disciplined use of parameterized queries, input validation, and context-aware checks. The combination of Gorilla Mux routing and secure database access prevents SQL Injection even when endpoints are authenticated via HMAC.