Bleichenbacher Attack in Fiber with Jwt Tokens

A Bleichenbacher attack is a cryptographic padding oracle exploit that targets RSA-based encryption and signature schemes. When JWT tokens use RS256 (RSA Signature with SHA-256), the token verification step performs RSA decryption and checks the padding structure. If the server exposes different error responses or timing differences between a valid padding error and other failures, an attacker can iteratively query the endpoint and recover the plaintext or forge a token without the private key.

In the Fiber web framework for Go, this risk arises when JWT validation is configured in a way that distinguishes between a bad signature/padding failure and other errors. For example, if the application returns a 401 for invalid signatures but a 400 for malformed tokens, or if error messages differ, these observable behaviors act as an oracle. An attacker can automate requests with modified tokens to learn about signature validity, eventually recovering the JWT or forging one. This is especially relevant when endpoints accept unsigned tokens or tokens with algorithm:none and the server fails to enforce strict algorithm checks.

Consider a Fiber route that parses an Authorization header and validates a JWT using an RSA public key. If the JWT library returns specific padding-related errors and the handler maps those to distinct HTTP statuses or response bodies, the endpoint becomes a padding oracle. In a typical RS256 flow, the server decrypts the RSA signature using the public key; if padding is invalid, the library signals a specific error. By measuring response codes and times, an attacker can adaptively choose ciphertexts and infer the plaintext, bypassing intended authentication.

To illustrate, assume a token verification pattern that decodes the token, verifies the signature, and then checks claims. If verification fails due to padding issues and the server reacts differently than when the token is simply malformed, the distinction can be leveraged. This is compounded when endpoints accept tokens with weak or missing key material or when public keys are fetched from untrusted sources without proper validation, enabling an attacker to substitute a key that yields more informative errors.

Using middleBrick, you can detect whether your Fiber endpoints expose JWT verification behavior that could facilitate a Bleichenbacher attack. The scanner runs unauthenticated checks across multiple security categories, including Authentication and Input Validation, to identify timing differences or inconsistent error handling that may act as an oracle for RSA-based JWT tokens. Findings include actionable guidance to ensure uniform error handling and strict algorithm enforcement, reducing the attack surface without requiring internal architecture details.

Remediation centers on making JWT verification side-channel resistant and strictly enforcing the expected algorithm. Ensure that all verification failures produce the same HTTP status and generic message, and avoid exposing internal details. Use a constant-time comparison where possible and validate the token algorithm before processing.

Example 1: Enforce RS256 and reject none/unsigned tokens in Fiber.

import (
  "github.com/gofiber/fiber/v2"
  "github.com/gofiber/fiber/v2/middleware/jwt"
)

func main() {
  app := fiber.New()
  config := jwt.Config{
    SigningKey:   []byte(`REPLACE_WITH_RSA_PUBLIC_KEY_BYTES`),
    SigningMethod: jwt.SigningMethodRS256,
    ContextKey:   "user",
    ErrorHandler: func(c *fiber.Ctx, err error) error {
      // Always return the same status and generic message
      return c.Status(fiber.StatusUnauthorized).JSON(fiber.Map{
        "error": "invalid_token",
        "message": "authentication failed",
      })
    },
  }
  app.Use(jwt.New(config))

  app.Get("/protected", func(c *fiber.Ctx) error {
    user := c.Locals("user").(*jwt.Token)
    // proceed only if token is valid and algorithm is RS256
    return c.JSON(fiber.Map{"ok": true})
  })

  app.Listen(":3000")
}

Example 2: Validate algorithm explicitly and avoid accepting multiple methods.

import (
  "errors"
  "github.com/gofiber/fiber/v2"
  "github.com/gofiber/fiber/v2/middleware/jwt"
)

func verifyAlgorithm(token *jwt.Token) error {
  if token.Method.Alg() != "RS256" {
    return errors.New("invalid algorithm")
  }
  return nil
}

Example 3: Use a constant-time check for key material and ensure public key integrity.

import (
  "crypto/rsa"
  "crypto/x509"
  "encoding/pem"
  "errors"
)

func parsePublicKey(keyData []byte) (*rsa.PublicKey, error) {
  block, _ := pem.Decode(keyData)
  if block == nil || block.Type != "PUBLIC KEY" {
    return nil, errors.New("invalid key format")
  }
  pub, err := x509.ParsePKIXPublicKey(block.Bytes)
  if err != nil {
    return nil, err
  }
  if pubKey, ok := pub.(*rsa.PublicKey); ok {
    return pubKey, nil
  }
  return nil, errors.New("not an rsa public key")
}

These patterns emphasize strict algorithm enforcement, uniform error handling, and proper key parsing to mitigate padding oracle risks. When combined with continuous monitoring and scans that validate error consistency, you reduce the likelihood of a successful Bleichenbacher attack against JWT tokens served by Fiber.