Timing Attack in Fiber with Jwt Tokens

A timing attack in the context of Fiber applications that validate JWT tokens occurs when the token verification process exhibits variable execution time based on secret or token characteristics. In Fiber, routes often invoke JWT validation middleware before handling business logic. If the validation implementation uses a string comparison that short-circuits on the first mismatching character, an attacker can learn partial information about the secret or token by measuring response times.

Consider a JWT signed with HMAC using a server-side secret. During verification, the server recomputes the signature and compares it to the received signature. A naive byte-by-byte comparison stops as soon as a mismatch is found. This behavior causes faster responses when the first bytes differ and slower responses when the initial bytes match. An attacker can craft multiple tokens with guessed signatures and observe response times to progressively recover the secret or forge valid tokens.

Real-world attack patterns mirror known issues such as CVE-2020-28168, where timing discrepancies in signature verification enabled secret recovery. In a black-box scan, middleBrick runs authentication and input validation checks in parallel to detect timing anomalies in unauthenticated endpoints. When a JWT-protected route is present, the scanner tests whether response times correlate with specific token properties, indicating a potential vulnerability.

Additionally, JWT handling in Fiber may involve parsing claims, validating expiration, and verifying issuer/audience. If these steps are not constant-time, side-channel information can leak. For example, returning distinct error messages for malformed tokens versus valid-but-wrong-signature tokens can aid an attacker in refining guesses. middleBrick’s LLM/AI Security checks specifically probe for system prompt leakage and unsafe consumption patterns that could amplify timing-based information disclosure in AI-integrated endpoints.

To illustrate a typical Fiber JWT setup that may be susceptible if not implemented carefully, the following code shows standard JWT validation without explicit constant-time safeguards:

const jwt = require('jsonwebtoken');
const express = require('express');
const app = express();

const SECRET = 'my-super-secret-key';

app.get('/protected', (req, res) => {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const token = authHeader.split(' ')[1];
  try {
    const decoded = jwt.verify(token, SECRET);
    res.json({ message: 'Access granted', user: decoded });
  } catch (err) {
    if (err.name === 'TokenExpiredError') {
      res.status(401).json({ error: 'Token expired' });
    } else if (err.name === 'JsonWebTokenError') {
      res.status(401).json({ error: 'Invalid token' });
    } else {
      res.status(500).json({ error: 'Internal error' });
    }
  }
});

app.listen(3000, () => console.log('Server running on port 3000'));

While the example above uses jsonwebtoken, the underlying verification routine may still perform non-constant-time comparisons depending on the library version and configuration. middleBrick’s scan would flag inconsistent response behavior under the Authentication and Input Validation checks, guiding remediation toward safer implementations.

Remediation focuses on ensuring JWT verification runs in constant time and does not leak information via timing or error messages. The primary defense is to rely on the underlying library’s verified constant-time comparison where available and to standardize error handling.

Update your validation logic to avoid branching on signature correctness and to return uniform error responses. For JWT verification in Fiber using jsonwebtoken, you can refactor the handler to minimize timing variance:

const jwt = require('jsonwebtoken');
const express = require('express');
const app = express();

const SECRET = 'my-super-secret-key';

function verifyTokenConstantTime(token, secret) {
  try {
    // decode without verification first to ensure consistent shape
    const decoded = jwt.decode(token, { complete: true });
    if (!decoded) {
      // Return a verified error path to keep timing stable
      return { error: 'Invalid token' };
    }
    // Use verify which performs constant-time comparison in modern versions
    const payload = jwt.verify(token, secret);
    return { payload };
  } catch (err) {
    // Always return a generic error to avoid information disclosure
    return { error: 'Invalid token' };
  }
}

app.get('/protected', (req, res) => {
  const authHeader = req.headers.authorization;
  if (!authHeader || !authHeader.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Unauthorized' });
  }
  const token = authHeader.split(' ')[1];
  const result = verifyTokenConstantTime(token, SECRET);
  if (result.error) {
    return res.status(401).json({ error: result.error });
  }
  res.json({ message: 'Access granted', user: result.payload });
});

app.listen(3000, () => console.log('Server running on port 3000'));

Key practices include using jwt.decode to inspect token structure without verification for early shape checks, ensuring jwt.verify is called in a try-catch to avoid throwing distinct errors, and standardizing error messages. Middleware can further mitigate risks by enforcing strict content-type and header checks before token processing.