Session Fixation in Buffalo with Jwt Tokens

Session fixation occurs when an application forces or permits a user to use a known session identifier. In Buffalo, this risk can intersect with JWT usage when JWTs are used for session-like authentication without proper issuance safeguards. Even though JWTs are typically stateless, developers sometimes store a JWT in a session cookie or use a session to hold a JWT before it is propagated, creating a fixation window.

With JWT tokens in Buffalo, the vulnerability arises when the server issues a JWT to an unauthenticated user and then reuses that same token after authentication. For example, if a user visits the site and receives a JWT identifying them as "guest", and after login the server keeps the same JWT and merely updates its claims, an attacker can craft a link with a known JWT and trick a victim into authenticating under that token. Because JWTs are self-contained, the server may trust the embedded identity without ensuring the token was freshly issued post-authentication.

In Buffalo, if you use a session store alongside JWTs (e.g., storing the JWT in the session), you may inadvertently preserve the original token across authentication. This can happen when middleware reads an existing JWT from a cookie or header and reuses it after the user logs in, rather than invalidating the old token and issuing a new one. Attackers can leverage this by sending a victim a URL containing a predictable or known JWT, and after the victim authenticates, the server continues to accept that JWT, granting the attacker access.

The API security scanner checks such scenarios under the Authentication and BOLA/IDOR checks, flagging cases where authentication does not rotate or bind the token to the authenticated context. Without explicit token rotation or binding to a fresh context, an attacker can fixate a token and maintain access after the victim authenticates.

To detect this during a scan, middleBrick runs unauthenticated probes that simulate a known JWT being used before and after authentication, checking whether the server continues to accept it. This is part of the LLM/AI Security and Authentication checks that map to OWASP API Top 10 and other compliance frameworks, ensuring you understand the risk when JWTs are mishandled in session contexts.

Remediation focuses on ensuring that after a user authenticates, any prior JWT is invalidated and a new token is issued. In Buffalo, this typically means regenerating the JWT claims and ensuring the token is not reused across authentication boundaries. Below are concrete code examples demonstrating secure handling.

Example 1: Fresh JWT issuance after login

When a user logs in, create a new JWT with a fresh jti (JWT ID) and issued-at timestamp. Do not reuse a JWT that was issued before authentication.

use github.com/gobuffalo/buffalo
use github.com/gobuffalo/buffalo/middleware
use github.com/dgrijalva/jwt-go

func Login(c buffalo.Context) error {
    // Validate credentials
    user, err := authenticate(c.Param("email"), c.Param("password"))
    if err != nil {
        return c.Render(401, r.JSON(map[string]string{"error": "invalid_credentials"}))
    }

    // Create a fresh token
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
        "sub":   user.ID,
        "email": user.Email,
        "jti":   generateUUID(), // Ensure uniqueness
        "iat":   time.Now().Unix(),
        "exp":   time.Now().Add(time.Hour * 24).Unix(),
    })

    tokenString, err := token.SignedString([]byte(os.Getenv("JWT_SECRET")))
    if err != nil {
        return c.Render(500, r.JSON(map[string]string{"error": "could_not_generate_token"}))
    }

    // Set in a secure, HttpOnly cookie
    c.Response().Cookie(&http.Cookie{
        Name:     "access_token",
        Value:    tokenString,
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteStrictMode,
        Path:     "/",
    })

    return c.Redirect(303, "/dashboard")
}

Example 2: Middleware that rejects tokens without fresh context

Ensure tokens are validated and, if necessary, prompt re-authentication rather than accepting an old token. You can check the jti claim against a revocation store or require re-login when privileges change.

func JWTAuthMiddleware(next buffalo.Handler) buffalo.Handler {
    return func(c buffalo.Context) error {
        cookie, err := c.Request().Cookie("access_token")
        if err != nil {
            return c.Render(401, r.JSON(map[string]string{"error": "unauthorized"}))
        }

        token, err := jwt.Parse(cookie.Value, func(token *jwt.Token) (interface{}, error) {
            return []byte(os.Getenv("JWT_SECRET")), nil
        })
        if err != nil || !token.Valid {
            return c.Render(401, r.JSON(map[string]string{"error": "invalid_token"}))
        }

        // Optionally enforce fresh issuance after login by checking custom claims
        if claims, ok := token.Claims.(jwt.MapClaims); ok {
            // Example: require re-auth for sensitive actions if token lacks reauth timestamp
            if _, hasReauth := claims["reauth_at"].(float64); !hasReauth {
                // Trigger re-authentication or additional verification
                return c.Render(403, r.JSON(map[string]string{"error": "reauthentication_required"}))
            }
        }

        return next(c)
    }
}

Example 3: Clear previous tokens on password change

When credentials change, invalidate any existing JWTs by rotating secrets or maintaining a per-user token version (jti prefix or jwt_version claim). This prevents continued use of a token issued before the credential update.

func ChangePassword(c buffalo.Context) error {
    userID := c.Param("user_id")
    newPassword := c.Param("new_password")

    // Update password
    if err := updatePassword(userID, newPassword); err != nil {
        return c.Render(500, r.JSON(map[string]string{"error": "could_not_change_password"}))
    }

    // Invalidate previous tokens: rotate secret or increment version in DB
    rotateJWTVersionForUser(userID)

    // Issue a new token explicitly after rotation
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
        "sub":   userID,
        "jti":   generateUUID(),
        "iat":   time.Now().Unix(),
        "exp":   time.Now().Add(time.Hour * 24).Unix(),
        "jwt_version": getCurrentJWTVersion(userID),
    })
    tokenString, _ := token.SignedString([]byte(os.Getenv("JWT_SECRET")))

    c.Response().Cookie(&http.Cookie{
        Name:     "access_token",
        Value:    tokenString,
        HttpOnly: true,
        Secure:   true,
        SameSite: http.SameSiteStrictMode,
        Path:     "/",
    })

    return c.Redirect(303, "/profile")
}