Replay Attack in Chi

Replay attacks in Chi-based APIs exploit the framework's minimalist design by resubmitting valid, state-changing requests to trigger unintended duplicate operations. Chi, as a lightweight router for Go's net/http, provides no built-in protections against request replay; it simply routes requests to handlers. The vulnerability arises entirely from handler logic that fails to enforce request uniqueness.

A typical attack pattern targets financial or resource-modification endpoints. Consider a Chi handler for a funds transfer:

func transferHandler(w http.ResponseWriter, r *http.Request) {
    // Extract parameters (vulnerable: no replay protection)
    from := r.URL.Query().Get("from")
    to := r.URL.Query().Get("to")
    amount, _ := strconv.Atoi(r.URL.Query().Get("amount"))

    // Perform transfer
    if err := db.Transfer(from, to, amount); err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
    w.Write([]byte("Transfer successful"))
}

An attacker who intercepts a legitimate request (e.g., POST /transfer?from=user1&to=user2&amount=100) can replay it repeatedly, draining the sender's account. Chi's routing does not interfere; the handler executes blindly each time.

Another Chi-specific manifestation involves middleware chaining. If a middleware (e.g., for authentication) passes the request downstream without validating request freshness, subsequent handlers remain exposed. For example, a JWT authentication middleware that validates the token but does not check a nonce or timestamp allows replayed requests with the same token to proceed.

Chi's lack of opinionated state management means developers must manually implement idempotency controls. Common oversights include:

• Missing Idempotency-Key header validation.
• No nonce tracking in sessions or distributed caches.
• Reliance on client-generated timestamps without server-side verification.

These gaps align with OWASP API Security Top 10 API2:2023 – Broken Authentication (if tokens are replayed) and API5:2023 – Broken Function Level Authorization (if replay bypasses rate limits or quotas).

Detecting replay vulnerabilities in Chi APIs requires testing for duplicate request acceptance. Since Chi itself is stateless, detection focuses on handler-side idempotency failures. middleBrick automates this via black-box scanning: it submits a request, records the response, then resubmits the identical request (preserving headers, body, method) and compares outcomes.

For a Chi endpoint like POST /api/orders, middleBrick’s scan would:

1. Send an initial request to create an order, capturing the response status and body (e.g., 201 Created with an order ID).
2. Immediately resend the same request.
3. If the server returns 200 OK or another success code with a new order ID, the endpoint is vulnerable to replay. A proper implementation should return 409 Conflict or 200 OK with the original order ID.

middleBrick’s BOLA/IDOR check (one of its 12 parallel scans) flags this as a broken authorization pattern because replay often circumvents intended access controls—e.g., reusing a privileged request after session expiration. The scanner also inspects for missing Idempotency-Key headers in state-changing requests (POST/PUT/DELETE) and tests whether the server rejects duplicates even when the header is absent.

Consider this Chi middleware that lacks replay checks:

r.Use(func(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // Authentication only – no replay protection
        token := r.Header.Get("Authorization")
        if !validateToken(token) {
            http.Error(w, "Unauthorized", http.StatusUnauthorized)
            return
        }
        next.ServeHTTP(w, r)
    })
})

middleBrick would detect that after authenticating once, subsequent replays of the same authenticated request still succeed. The scanner’s report would highlight the endpoint, show the duplicated response, and map the finding to OWASP API2:2023.

To scan your own Chi APIs, use the middleBrick CLI:

middlebrick scan https://your-chi-api.com/transfer

The output includes a replay test result in the BOLA/IDOR category. In the Web Dashboard, you can track whether replay vulnerabilities persist across deployments.

Remediating replay attacks in Chi requires implementing idempotency at the handler or middleware level. Chi’s simplicity means you must explicitly add these checks; the framework does not provide them. The standard approach is to enforce Idempotency-Key headers or nonces with server-side storage.

Idempotency-Key Middleware
Store processed keys in a fast cache (e.g., Redis, Memcached) or in-memory store with a TTL. Here’s a Chi middleware using an in-memory map (suitable for single-node deployments):

var idempotencyKeys = sync.Map{}

func idempotencyMiddleware() func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            if r.Method == http.MethodPost || r.Method == http.MethodPut || r.Method == http.MethodDelete {
                key := r.Header.Get("Idempotency-Key")
                if key == "" {
                    // Optional: reject missing keys or generate a server-side key
                    http.Error(w, "Idempotency-Key required", http.StatusBadRequest)
                    return
                }
                if _, loaded := idempotencyKeys.LoadOrStore(key, true); loaded {
                    http.Error(w, "Duplicate request", http.StatusConflict)
                    return
                }
                // Set TTL (e.g., 24h) – in production, use Redis with EXPIRE
                time.AfterFunc(24*time.Hour, func() {
                    idempotencyKeys.Delete(key)
                })
            }
            next.ServeHTTP(w, r)
        })
    }
}

Apply this middleware to vulnerable routes:

r := chi.NewRouter()
r.Use(idempotencyMiddleware())
r.Post("/transfer", transferHandler)

Nonce-Based Replay Prevention
For APIs using session tokens or JWTs, embed a nonce in the token or request and track used nonces server-side. Example with a database table used_nonces (nonce TEXT PRIMARY KEY, expires_at TIMESTAMP):

func nonceMiddleware(db *sql.DB) func(http.Handler) http.Handler {
    return func(next http.Handler) http.Handler {
        return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
            nonce := r.Header.Get("X-Nonce")
            if nonce == "" {
                next.ServeHTTP(w, r)
                return
            }
            var exists bool
            err := db.QueryRow("SELECT 1 FROM used_nonces WHERE nonce = $1 AND expires_at > NOW()", nonce).Scan(&exists)
            if err == nil && exists {
                http.Error(w, "Replay detected", http.StatusConflict)
                return
            }
            // Insert nonce with 5-minute expiry
            _, _ = db.Exec("INSERT INTO used_nonces (nonce, expires_at) VALUES ($1, NOW() + INTERVAL '5 minutes')", nonce)
            next.ServeHTTP(w, r)
        })
    }
}

Testing Your Fix
After deploying middleware, rescan with middleBrick. The BOLA/IDOR category should no longer flag replay issues. For continuous enforcement, add the middleBrick GitHub Action to your CI/CD pipeline to fail PRs that introduce replay-prone endpoints:

- name: Scan API with middleBrick
  uses: middlebrick/github-action@v1
  with:
    url: ${{ env.STAGING_API_URL }}
    fail_below_score: 80

This ensures Chi APIs maintain idempotency guarantees across releases.

Q: How does middleBrick test for replay attacks in Chi APIs?
A: middleBrick automatically resubmits identical requests to state-changing endpoints (POST/PUT/DELETE) and checks if the server processes them multiple times. If duplicate resources are created or operations repeated, it flags a replay vulnerability in the BOLA/IDOR category with evidence.

Q: Does Chi’s router have built-in replay protection?
A: No. Chi is a routing library only; it does not inspect request headers or enforce idempotency. All replay prevention must be implemented in your handlers or custom middleware, as shown in the remediation examples.