Side Channel Attack in Chi with Cockroachdb

A side channel attack in the context of a web framework like Chi with CockroachDB as the backend does not exploit a flaw in CockroachDB itself, but rather observes indirect effects—such as timing differences or error behavior—leaked through the HTTP request lifecycle. Chi’s minimal middleware and explicit routing make it straightforward to instrument, but if request handling time or error messages vary based on sensitive data, an attacker can infer information without direct access to the database.

Consider a login flow where a user-supplied username is looked up in CockroachDB. If the application performs a constant-time comparison only after retrieving a candidate row, the time taken for a nonexistent user can differ from a valid user because the database round-trip occurs only when a row exists. An attacker can measure response times across many requests and gradually infer valid usernames. In Chi, this typically arises when middleware is arranged to call the next handler prematurely or when database calls are placed inconsistently across routes.

CockroachDB, being a distributed SQL database, introduces additional considerations. Network latency between application nodes and database nodes can add variability to query durations. If error handling leaks whether a row exists—for example, returning a 401 for bad credentials versus a 404 for a nonexistent user—this distinction becomes a side channel. The database’s geo-partitioning or replication settings might also affect latency patterns, giving an attacker further timing hints depending on how the request traverses the cluster.

Another vector arises from structured error messages. If a Chi route handler returns detailed database errors to the client (e.g., violating a uniqueness constraint), an attacker can distinguish between different failure conditions. Combined with timing differences in how Chi routes dispatch to handlers, this can reveal which validation or authentication checks were triggered. For instance, a route that first checks a cache and then queries CockroachDB will exhibit different timing and error paths depending on cache hit versus miss, potentially exposing internal logic to an observant attacker.

Because middleBrick tests unauthenticated attack surfaces and includes checks for Input Validation and Data Exposure, it can flag inconsistencies in timing and error handling across Chi routes that interact with CockroachDB. While the scanner does not measure time directly in its standard checks, it can identify patterns—such as verbose error messages or branching logic that depends on database presence—that commonly enable side channel inferences. Remediation focuses on making request handling paths and error responses consistent and independent of sensitive data outcomes.

Remediation in Chi should standardize response times and error messages for equivalent authentication or data lookup outcomes, and avoid branching logic that reveals internal state through timing or responses. Below are concrete, realistic code examples for Chi routes that interact with CockroachDB.

Consistent authentication flow

Use a fixed-duration hash comparison and a constant-time delay for failed attempts to obscure timing differences. This example uses golang.org/x/crypto/bcrypt for password hashing and a dummy lookup to ensure the operation takes similar time regardless of user existence.

package main

import (
    "context"
    "crypto/subtle"
    "net/http"
    "time"

    "github.com/go-chi/chi/v5"
    "github.com/jackc/pgx/v5/pgxpool"
    "golang.org/x/crypto/bcrypt"
)

var db *pgxpool.Pool

func loginHandler(w http.ResponseWriter, r *http.Request) {
    const dummyHash = "$2a$10$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    var req struct {
        Username string `json:"username"`
        Password string `json:"password"`
    }
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, `{"error": "invalid_request"}`, http.StatusBadRequest)
        return
    }

    // Always perform a DB lookup for a plausible user; if not found, use a dummy row.
    var storedHash string
    row := db.QueryRow(r.Context(), "SELECT password_hash FROM users WHERE username = $1", req.Username)
    err := row.Scan(&storedHash)
    if err != nil {
        storedHash = dummyHash // ensures timing similarity
    }

    // Constant-time comparison
    if subtle.ConstantTimeCompare([]byte(storedHash), []byte(dummyHash)) == 1 {
        // Even if hashes differ, sleep to approximate lookup time
        time.Sleep(250 * time.Millisecond)
        http.Error(w, `{"error": "invalid_credentials"}`, http.StatusUnauthorized)
        return
    }

    if bcrypt.CompareHashAndPassword([]byte(storedHash), []byte(req.Password)) != nil {
        time.Sleep(250 * time.Millisecond)
        http.Error(w, `{"error": "invalid_credentials"}`, http.StatusUnauthorized)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusOK)
    w.Write([]byte(`{"status": "ok"}`))
}

import (
    "database/sql"
    "fmt"
    "net/http"

    _ "github.com/lib/pq"
)

func createUserHandler(w http.ResponseWriter, r *http.Request) {
    var payload struct {
        Username string `json:"username"`
        Email    string `json:"email"`
    }
    if err := json.NewDecoder(r.Body).Decode(&payload); err != nil {
        http.Error(w, `{"error": "bad_request"}`, http.StatusBadRequest)
        return
    }

    // Use an upsert to handle uniqueness on the DB side
    query := `
        INSERT INTO users (username, email) VALUES ($1, $2)
        ON CONFLICT (username) DO NOTHING
        RETURNING id`
    var id sql.NullInt64
    err := db.QueryRowContext(r.Context(), query, payload.Username, payload.Email).Scan(&id)
    if err != nil {
        // Map CockroachDB errors to a generic response
        http.Error(w, `{"error": "conflict_or_server_error"}`, http.StatusConflict)
        return
    }
    if id.Valid {
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusCreated)
        w.Write([]byte(fmt.Sprintf(`{"id": %d}`, id.Int64)))
        return
    }
    // ON CONFLICT DO NOTHING returned no row; treat as conflict without details
    http.Error(w, `{"error": "conflict_or_server_error"}`, http.StatusConflict)
}

func secureErrorMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // Wrap the response writer to intercept status and body if needed
        ww := middleware.NewWrapResponseWriter(w, r.ProtoMajor)
        next.ServeHTTP(ww, r)
        // If you need to sanitize body on error, do it here uniformly
    })
}