Symlink Attack in Feathersjs with Jwt Tokens

A symlink attack in a Feathersjs service that uses Jwt tokens occurs when an attacker leverages file-system path traversal to read or overwrite files that are outside the intended directory. This typically happens when the service accepts user-supplied paths or filenames and uses them directly in filesystem operations (for example, writing uploaded files or configuration data). If the service also relies on Jwt tokens for authentication and authorization, the attack surface expands because an attacker may first obtain or forge a Jwt to gain access to endpoints that handle file paths.

In Feathersjs, a common pattern is to configure a custom service that stores files on disk and records metadata in a database. If the API exposes endpoints such as PUT or POST that accept a path or filename field, and the server code resolves these directly with functions like fs.writeFileSync or fs.renameSync, an attacker can supply sequences like ../../../etc/passwd or crafted names containing null bytes or directory traversals. If the server resolves paths relative to a user-writable directory without canonicalizing and validating them, the attacker can escape the intended sandbox and read sensitive files or overwrite configuration and application files.

When Jwt tokens are involved, the attacker may need to authenticate to obtain a valid token or exploit weak token handling to impersonate a privileged user. For instance, if token validation is misconfigured or tokens contain overly broad permissions, an attacker can use a valid Jwt to call file-related endpoints they should not access. The vulnerability is not in Jwt itself but in how the Feathersjs application combines Jwt-based authorization with unsafe file-path handling. Path traversal and symlink resolution on the server can allow the attacker to redirect writes or reads to arbitrary locations, potentially bypassing intended access controls enforced by Jwt scopes or roles.

An example scenario: a Feathersjs service exposes an endpoint upload that accepts { path, filename, content }. The server resolves the destination as path.join(baseDir, path, filename). If path is user-supplied and not normalized, an attacker can send path: "../../secrets". If the API requires a Jwt token, the attacker might first exploit a weak token issuance flow to obtain a token, or reuse a token from a compromised session. The server processes the request with elevated file-system permissions and writes content into a sensitive directory. Later, the attacker can read or replace files, potentially achieving data exfiltration or persistence. This illustrates how Jwt tokens do not inherently protect against file-path manipulation; the server must validate and sanitize paths independently of authentication artifacts.

Remediation focuses on strict path validation and ensuring Jwt usage does not inadvertently elevate risk. Do not trust user-supplied path components; always resolve paths against a known base directory and canonicalize them. Use libraries to enforce that resolved paths remain within the allowed directory. Additionally, review Jwt payloads to avoid over-permissive scopes and ensure token validation is correctly configured.

Secure path handling with Jwt-authenticated Feathersjs services

Below is a secure example of a Feathersjs service that handles file uploads with Jwt tokens, emphasizing path canonicalization and validation.

const path = require('path');
const fs = require('fs');

// Utility to ensure a resolved path is within a base directory
function isWithinBase(base, target) {
  const targetResolved = path.resolve(target);
  const baseResolved = path.resolve(base);
  return targetResolved.startsWith(baseResolved + path.sep) || targetResolved === baseResolved;
}

app.use('/files', {
  async create(data, params) {
    const { filename, content, subpath } = data; // subpath from validated body
    const user = params.user; // authenticated user from Jwt

    // Validate filename to prevent directory traversal and unsafe characters
    if (!filename || typeof filename !== 'string' || !/^[\w\-\.]+$/.test(filename)) {
      throw new Error('Invalid filename');
    }

    // Build destination using controlled subpath and canonical checks
    const baseDir = '/srv/app/uploads';
    const requestedSubpath = subpath || '';
    // Normalize and forbid '..' segments explicitly
    const normalized = path.normalize(requestedSubpath).replace(/^(\.\.[\/\\])|(\/\.\.)/, '');
    const destination = path.join(baseDir, normalized);

    if (!isWithinBase(baseDir, destination)) {
      throw new Error('Path traversal not allowed');
    }

    // Ensure user is authorized for this subpath (example scope check)
    if (!user || !user.scopes || !user.scopes.includes('files:write')) {
      throw new Error('Unauthorized');
    }

    const fullPath = path.join(destination, filename);
    fs.writeFileSync(fullPath, content, { encoding: 'utf8' });

    return { path: fullPath, size: content.length };
  }
});

Key points in this example:

• isWithinBase canonicalizes both base and target paths and ensures the target remains inside the base directory.
• path.normalize is used cautiously followed by an explicit strip of leading .. segments to remove dangerous traversals.
• Jwt-derived user information is checked for required scopes (e.g., files:write) before allowing writes, demonstrating how authentication and authorization remain tied to business logic without relying on path trust.
• Filename is validated with a strict regex to avoid unexpected characters that could facilitate symlink tricks or injection.

Jwt token best practices alongside file operations

• Verify tokens using a robust library and check claims such as iss, aud, and expiration to prevent token misuse.
• Avoid embedding sensitive file-system paths or permissions inside the Jwt payload; keep tokens focused on identity and minimal scopes.
• Do not use Jwt secrets or keys as part of file names or paths, which could lead to confusion or injection.

By combining rigorous path validation with disciplined Jwt usage, you reduce the likelihood that authenticated requests can be leveraged for unintended file-system access.