HIGH zip slipfeathersjsjwt tokens

Zip Slip in Feathersjs with Jwt Tokens

Zip Slip in Feathersjs with Jwt Tokens — how this specific combination creates or exposes the vulnerability

Zip Slip is a path traversal vulnerability that occurs when an application constructs file paths using user-supplied input without proper validation or sanitization. In a Feathersjs application that uses Jwt Tokens for authentication, the risk is not that JWT parsing introduces path traversal, but that an authenticated endpoint (protected by JWT validation) exposes unsafe file operations. An attacker who obtains a valid JWT—through compromise, insecure storage, or token sidejacking—can exploit server-side logic that uses user-controlled values to build filesystem paths. For example, an upload route in Feathersjs may accept a filename or path field and join it with a base directory using naive concatenation or path.join with insufficient canonicalization. If the JWT provides identity context (e.g., user ID) that is also used to derive folder names, an attacker can supply crafted input such as ../../../etc/passwd. The JWT may make the endpoint appear authorized, but the vulnerability lies in path handling, not token validation. A scanner that tests unauthenticated attack surfaces will not find this; an authenticated scan with a valid JWT is required to exercise the endpoint and detect path traversal. MiddleBrick’s checks include Inventory Management and Unsafe Consumption, which can surface risky file operations when an OpenAPI spec describes parameters that influence filesystem paths. The presence of JWT authentication may reduce the scan’s unauthenticated coverage, so ensuring endpoints are tested with valid tokens through integration or manual review is important to uncover these issues in Feathersjs services.

Jwt Tokens-Specific Remediation in Feathersjs — concrete code fixes

Remediation focuses on secure path handling and strict validation of any user-controlled input used in filesystem operations, even when requests carry valid Jwt Tokens. Always resolve paths to their canonical form and enforce that resolved paths remain within an allowed base directory. Do not rely on JWT claims to authorize filesystem paths implicitly.

Secure path resolution example

const path = require('path');

// Safe file join in a Feathers service hook
function safeFilePath(baseDir, userSupplied) {
  const resolved = path.resolve(baseDir, userSupplied);
  if (!resolved.startsWith(path.resolve(baseDir))) {
    throw new Error('Invalid path: traversal attempt');
  }
  return resolved;
}

// Usage inside a Feathers before hook
app.service('uploads').hooks({
  before: {
    create: [context => {
      const baseDir = '/var/app/uploads';
      const filename = context.data.filename;
      context.data.fullPath = safeFilePath(baseDir, filename);
      return context;
    }]
  }
});

JWT-aware authorization without path assumptions

Do not embed filesystem paths in JWT claims or derive paths directly from user ID without strict validation. If user-specific directories are required, map claims to directories via a whitelist or database lookup, and validate against path traversal patterns explicitly.

Input validation and sanitization

const validName = /^[a-zA-Z0-9._-]+$/;
function validateFilename(name) {
  if (!validName.test(name)) {
    throw new Error('Invalid filename');
  }
}

Use of libraries

path built into Node.js for canonicalization; consider realpath-style checks in application logic.
Avoid concatenating strings to build paths; prefer path.join or path.resolve, and always assert the result is within the allowed directory.

Operational guidance

In Feathersjs, structure hooks to validate and sanitize before invoking service methods. Combine JWT verification (typically via an authentication hook) with explicit path checks so that a valid token does not implicitly grant unsafe filesystem access. MiddleBrick’s findings may highlight endpoints where path parameters lack canonicalization; use its remediation guidance to harden the implementation rather than altering JWT usage assumptions.

Frequently Asked Questions

Can a valid Jwt Token make a Zip Slip vulnerability harder to detect?

Yes. Because JWT authentication can make an endpoint appear authorized, automated unauthenticated scans may miss path traversal issues. Testing must include authenticated scenarios or manual review to detect Zip Slip in Feathersjs when JWTs are used.

Does JWT content itself need sanitization to prevent Zip Slip?

JWT claims should not be used to construct filesystem paths without strict validation. Sanitize and validate any user-influenced input—including claims mapped to paths—using allowlists and canonical path checks to prevent traversal regardless of token validity.

Zip Slip in Feathersjs with Jwt Tokens