HIGH session fixationfiberbasic auth

Session Fixation in Fiber with Basic Auth

Session Fixation in Fiber with Basic Auth — how this specific combination creates or exposes the vulnerability

Session fixation occurs when an application assigns a user a session identifier before authentication and does not regenerate it afterward. In the Go Fiber framework, this risk is amplified when Basic Authentication is used because the initial unauthenticated session can be tied to a predictable or attacker-supplied token. An attacker can set a known session cookie (or Authorization header state) and then trick a victim into authenticating with that same identifier. Because Basic Auth sends credentials on each request, the server may treat the authenticated request as a continuation of the pre‑auth session rather than establishing a new, server‑controlled session. If session regeneration is omitted after successful Basic Auth validation, the attacker’s session ID remains valid post‑login, allowing them to hijack the authenticated context.

Consider a scenario where a Fiber app uses a session store but does not rotate the session ID after confirming Basic Auth credentials. The application might validate Authorization: Basic base64(username:password) on a route, mark the session as authenticated, and continue using the same cookie/session value. Because the validation is performed on each request (Basic Auth is stateless per request), the server may lack a clear boundary between pre‑auth and post‑auth session states. This gap enables an attacker to craft a link with a known session identifier, have the victim authenticate via Basic Auth, and then reuse the identifier to access protected endpoints without re‑authenticating. MiddleBrick’s authentication and BOLA/IDOR checks are designed to detect such insecure session handling patterns, especially where authentication and session management boundaries are ambiguous.

When Basic Auth is used without TLS, the credentials are exposed on every request; session fixation compounds this by giving an attacker a valid authenticated session after observing a single successful login. Even with TLS, if the session identifier is not regenerated upon authentication, attackers who can predict or set the identifier before login can maintain access. MiddleBrick’s checks for authentication issues and insecure consumption highlight these risks by correlating authentication flows with session handling logic. The scanner does not fix the implementation but provides findings with remediation guidance so developers can tighten the boundary between authentication and session management.

Basic Auth-Specific Remediation in Fiber — concrete code fixes

To mitigate session fixation with Basic Auth in Fiber, ensure that session identifiers are regenerated immediately after successful authentication and that session state is decoupled from pre‑auth identifiers. Always enforce HTTPS to protect credentials in transit. Below are concrete, syntactically correct examples for a Fiber app using Basic Auth with secure session handling.

Secure Basic Auth with Session Regeneration in Fiber

package main

import (
    "github.com/gofiber/fiber/v2"
    "github.com/gofiber/fiber/v2/middleware/session"
    "github.com/gofiber/fiber/v2/utils"
    "net/http"
    "strings"
)

func main() {
    app := fiber.New()
    // Configure session storage (e.g., cookie store with secure settings)
    store := session.NewMemoryStore()
    app.Use(session.Middleware(store))

    app.Post("/login", func(c *fiber.Ctx) error {
        // Extract Basic Auth credentials
        auth := c.Get("Authorization")
        if auth == "" {
            return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "Authorization header required"})
        }
        const prefix = "Basic "
        if !strings.HasPrefix(auth, prefix) {
            return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "Invalid authorization type"})
        }
        payload, err := utils.Base64Decode(auth[len(prefix):])
        if err != nil {
            return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "Invalid encoding"})
        }
        parts := strings.SplitN(string(payload), ":", 2)
        if len(parts) != 2 || parts[0] != "validUser" || parts[1] != "correctPassword" {
            return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "Invalid credentials"})
        }

        // Regenerate session to prevent fixation
        session, err := c.Session()
        if err != nil {
            return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{"error": "session error"})
        }
        // Force a new session ID after successful authentication
        session.Regenerate()
        session.Set("authenticated", true)
        session.Set("username", parts[0])
        return c.JSON(fiber.Map{"message": "login successful"})
    })

    app.Get("/profile", func(c *fiber.Ctx) error {
        session, err := c.Session()
        if err != nil || !session.Get("authenticated").(bool) {
            return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{"error": "unauthorized"})
        }
        return c.JSON(fiber.Map{"user": session.Get("username")})
    })

    app.Listen(":3000")
}

Key points in the remediation:

  • Session regeneration (session.Regenerate()) is called immediately after validating Basic Auth credentials, ensuring that any pre‑auth session identifier is replaced with a new server‑controlled one.
  • The session state tracks authentication separately from the stateless Basic Auth credentials, preventing the server from conflating per‑request auth headers with a long‑lived session.
  • HTTPS should be enforced in production to protect the Base64‑encoded credentials on each request; the code assumes TLS termination at the frontend or load balancer.

For applications that avoid server‑side sessions and rely on stateless validation, ensure that tokens or context derived from Basic Auth are not reused from pre‑auth requests. MiddleBrick’s authentication checks can help identify whether session regeneration or token rotation is missing in your API implementation.

Frequently Asked Questions

Does using Basic Auth over HTTPS fully prevent session fixation?
Using Basic Auth over HTTPS protects the credentials in transit, but it does not prevent session fixation by itself. If the server does not regenerate the session identifier after authentication, an attacker can still fixate a session and reuse it post‑login. Always couple HTTPS with explicit session regeneration or token rotation after successful authentication.
How can I verify my Fiber app is not vulnerable to session fixation with Basic Auth?
Check that your authentication handler calls a session regeneration method (for server‑side sessions) or issues a new token (for stateless approaches) immediately after validating credentials. Review that pre‑auth and post‑auth session contexts are separate. Tools like MiddleBrick can scan your endpoints to detect missing regeneration patterns and related authentication boundary issues.