Replay Attack in Buffalo with Cockroachdb

A replay attack in a Buffalo application using CockroachDB typically occurs when an attacker captures a valid request—often including an authentication token or an idempotency key—and re-sends it to the server to perform an unintended action. Because CockroachDB is a distributed SQL database that provides strong consistency and serializable isolation by default, it does not inherently prevent a server from mistakenly processing the same request twice. The vulnerability arises at the application layer when the server lacks idempotency controls, unique request identifiers, or replay-safe transaction patterns.

In Buffalo, a common pattern is to create a record within a database transaction, relying on unique constraints to prevent duplication. However, if the client generates an idempotency key (such as a client-side UUID) and the server does not check this key in a concurrency-safe way before committing, a replayed request can pass validation and insert a duplicate record. CockroachDB’s serializable isolation means that two concurrent transactions inserting the same unique key will result in a retryable serialization error for one, but if the server does not handle retries carefully—such as re-fetching state or re-applying business logic—the second request may still succeed on a later attempt, leading to double writes or unauthorized operations.

Consider an endpoint that initiates a fund transfer. An attacker who captures a request containing a user ID, amount, and a nonce or timestamp may resend the same request. If the server uses CockroachDB only to enforce uniqueness on a database column (e.g., a composite unique index on user_id and external_id) but does not validate that the external_id is single-use across retries, the transaction may commit twice if the first transaction retries internally due to serialization failure. The server might also log or return a success response after the first commit but then inadvertently process the replayed request as new because the application layer does not track processed requests in a durable, queryable store with proper conflict resolution.

Additionally, if the application embeds nonces or timestamps in JWTs or session cookies without server-side state tracking, a replayed token can be accepted within its validity window. CockroachDB can store metadata about processed requests (for example, a hash of the request payload combined with a nonce), but if the server fails to perform a deterministic check within the transaction—such as using INSERT ... ON CONFLICT DO NOTHING and inspecting the number of affected rows—it may treat a replay as a new, valid operation. The interplay between Buffalo’s convention-over-configuration request handling and CockroachDB’s strong consistency means developers must explicitly design idempotency at the transaction and application level rather than relying on the database to reject all duplicates automatically.

To mitigate replay attacks in a Buffalo application backed by CockroachDB, implement idempotency at the transaction and application layer with explicit uniqueness checks and safe retry handling. Use unique constraints and INSERT ... ON CONFLICT patterns to ensure that duplicate requests are detected and discarded safely.

Example 1: Idempotent fund transfer with CockroachDB unique index

-- SQL: create a table with a uniqueness constraint on idempotency key
CREATE TABLE transfers (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL,
    amount NUMERIC NOT NULL,
    idempotency_key TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    UNIQUE (user_id, idempotency_key)
);

// Go: Buffalo handler with idempotent insert
func TransferHandler(c buffalo.Context) error {
    userID := c.Param("user_id")
    amount, err := strconv.ParseFloat(c.Param("amount"), 64)
    if err != nil {
        return c.Render(400, r.JSON(map[string]string{"error": "invalid amount"}))
    }
    idempotencyKey := c.Request().Header.Get("Idempotency-Key")
    if idempotencyKey == "" {
        return c.Render(400, r.JSON(map[string]string{"error": "missing idempotency key"}))
    }

    tx, err := c.Tx()
    if err != nil {
        return c.Render(500, r.JSON(map[string]string{"error": "server error"}))
    }
    defer tx.Rollback()

    var existingID string
    err = tx.QueryRow(`
        SELECT id FROM transfers 
        WHERE user_id = $1 AND idempotency_key = $2
    `, userID, idempotencyKey).Scan(&existingID)
    if err == nil {
        // Already processed this request; return previous response metadata if stored
        return c.Render(200, r.JSON(map[string]string{"id": existingID, "status": "already_processed"}))
    }
    // Proceed with transfer logic (e.g., update balances within same transaction)
    var newTransferID string
    err = tx.QueryRow(`
        INSERT INTO transfers (user_id, amount, idempotency_key)
        VALUES ($1, $2, $3)
        RETURNING id
    `, userID, amount, idempotencyKey).Scan(&newTransferID)
    if err != nil {
        // Unique violation or serialization error; safe to treat as conflict
        return c.Render(409, r.JSON(map[string]string{"error": "conflict or duplicate"}))
    }
    if err := tx.Commit(); err != nil {
        return c.Render(500, r.JSON(map[string]string{"error": "commit failed"}))
    }
    return c.Render(201, r.JSON(map[string]string{"id": newTransferID, "status": "created"}))
}

Example 2: Using ON CONFLICT DO NOTHING to safely deduplicate

// Go: Insert with ON CONFLICT and check rows affected
func CreateOrderHandler(c buffalo.Context) error {
    orderID := c.Param("order_id") // client-supplied, used as idempotency key
    userID := c.Param("user_id")
    var payload OrderPayload
    if err := c.Bind(&payload); err != nil {
        return c.Render(400, r.JSON(map[string]string{"error": "invalid payload"}))
    }

    tx, err := c.Tx()
    if err != nil {
        return c.Render(500, r.JSON(map[string]string{"error": "server error"}))
    }
    defer tx.Rollback()

    var insertedID string
    // Use a composite uniqueness constraint on (user_id, order_id)
    err = tx.QueryRow(`
        INSERT INTO orders (id, user_id, data)
        VALUES ($1, $2, $3)
        ON CONFLICT (user_id, id) DO NOTHING
        RETURNING id
    `, orderID, userID, payload.JSON).Scan(&insertedID)

    if err == sql.ErrNoRows {
        // Conflict: order already exists; fetch and return stored data
        var existingData string
        tx.QueryRow(`SELECT data FROM orders WHERE user_id = $1 AND id = $2`, userID, orderID).Scan(&existingData)
        return c.Render(200, r.JSON(map[string]string{"id": orderID, "data": existingData, "status": "exists"}))
    } else if err != nil {
        return c.Render(500, r.JSON(map[string]string{"error": "server error"}))
    }

    if err := tx.Commit(); err != nil {
        return c.Render(500, r.JSON(map[string]string{"error": "commit failed"}))
    }
    return c.Render(201, r.JSON(map[string]string{"id": orderID, "status": "created"}))
}

Best practices summary

• Use a client-supplied idempotency key and enforce uniqueness in the database via a composite unique constraint.
• Perform existence checks or use INSERT ... ON CONFLICT DO NOTHING within the same transaction to avoid race conditions.
• Return the same HTTP status and cached response for detected duplicates to prevent side effects.
• Store metadata such as request hash or response body in CockroachDB to aid auditing and debugging.