Session Fixation in Chi with Cockroachdb

Session fixation occurs when an application accepts a session identifier provided by the client without ensuring it was generated server-side. In a Chi-based service that uses Cockroachdb as the session store, the risk arises when session identifiers are accepted in cookies or headers and then used to look up session data in Cockroachdb without validation or regeneration. Chi is a composable router for Clojure web applications and does not enforce session management by itself; developers typically introduce sessions via libraries such as buddy or custom middleware. If your Chi routes read a session ID from a cookie (e.g., :session-id) and directly query Cockroachdb using that ID, an attacker can fixate the session by persuading a victim to use a known session identifier.

Consider a scenario where Cockroachdb stores session records in a table keyed by session ID. If the Chi application does not issue a new session ID upon authentication, an attacker can set session_id=attacker_chosen in the victim’s browser (via URL parameter or a crafted link), authenticate as the victim, and then use the known session ID to access the victim’s session data in Cockroachdb. This is a classic session fixation vector, and Cockroachdb’s role is passive: it faithfully returns whatever the application asks for, assuming the query is authorized. The exposure is not in Cockroachdb itself but in how the Chi application integrates with the database: trusting client-supplied identifiers and failing to rotate the session token after privilege changes.

To illustrate, a vulnerable Chi handler might look like this: it reads a session token from a header, fetches session metadata from Cockroachdb, and uses it to authorize requests without verifying that the session was issued by the server:

(defn vulnerable-session-handler [request]
  (let [session-id (get-in request [:headers "x-session-id"])
        session (jdbc/execute! db ["SELECT user_id, expires_at FROM sessions WHERE id = ?" [session-id]])
        ;; proceed with authorization based on session
        ]
    ;; ...
    ))

An attacker can set x-session-id to any value before authentication; after the victim logs in, the same ID maps to an authenticated session in Cockroachdb, allowing the attacker to hijack the session. Additionally, if the Chi application exposes session identifiers in URLs or logs, Cockroachdb entries may inadvertently reference predictable identifiers, increasing the risk of enumeration or leakage. The combination therefore creates a vulnerability surface: Chi’s flexibility in session handling plus Cockroachdb’s role as a session store means the developer must enforce strict session lifecycle controls.

Mitigations include regenerating session identifiers after authentication and ensuring session IDs are opaque, server-generated values never echoed back to the client in URLs or predictable headers. The Chi application should treat any client-supplied session identifier as untrusted and always validate it against server-side state stored in Cockroachdb.

Remediation focuses on ensuring session identifiers are generated server-side, never trusted from the client, and rotated after authentication. With Cockroachdb, store sessions with server-generated UUIDs and bind them to additional context such as IP or user-agent if appropriate, while avoiding over-reliance on client-supplied values.

Use a cryptographically secure random generator to create session IDs and store them in Cockroachdb. Here is a robust pattern for Chi that creates a new session after login and invalidates any previously supplied identifier:

(ns myapp.session
  (:require [clojure.string :as str]
            [next.jdbc :as jdbc]
            [java-uuid :refer [random-uuid]]))

(defn create-session! [user-id db]
  (let [session-id (str (random-uuid))
        expires-at (java.util.Date. (+ (System/currentTimeMillis*) (* 30 24 60 60 1000)))]
    (jdbc/execute! db ["INSERT INTO sessions (id, user_id, expires_at) VALUES (?, ?, ?)"
                       session-id user-id expires-at])
    session-id))

(defn authenticated-session-handler [request db]
  (let [user-id (:user-id request) ;; after authentication
        session-id (create-session! user-id db)
        response (ring.util.response/redirect "/dashboard")]
    (-> response
        (ring.util.response/set-cookie (ring.util.response/cookie {:name "session_id"
                                                                  :value session-id
                                                                  :http-only true
                                                                  :secure true
                                                                  :path "/"}))
        (assoc :session-id session-id))))

This approach ensures the session ID is generated server-side, stored securely in Cockroachdb, and delivered to the client via a secure, HTTP-only cookie. Note that the Chi routes should read the session ID exclusively from the cookie and perform a server-side lookup in Cockroachdb, never from headers or URL parameters.

Additionally, enforce strict validation when reading session data. For example, always parameterize queries to prevent SQL injection and verify session integrity:

(defn get-session [session-id db]
  (jdbc/execute-one! db ["SELECT id, user_id, expires_at FROM sessions WHERE id = ? AND expires_at > NOW()" session-id]))

In the Chi routing tree, compose middleware that calls get-session using the cookie value and rejects requests with invalid or missing sessions. This pattern removes any reliance on client-provided identifiers and closes the fixation vector by ensuring every authenticated session is tied to a server-generated token stored in Cockroachdb.

For continuous monitoring, integrate the middleBrick CLI to scan your Chi endpoints and detect misconfigurations related to session handling. The middleBrick GitHub Action can also enforce security thresholds in CI/CD, ensuring future changes do not reintroduce session fixation risks.