Symlink Attack in Feathersjs with Dynamodb

A symlink attack in a Feathersjs service that uses Dynamodb can occur when user-controlled file paths or keys influence file system operations performed by server-side code, even if the primary data store is Dynamodb. Feathersjs applications often add file handling via hooks or custom services (for example, processing uploads or storing references). If a hook or service builds file paths by concatenating user input without canonicalization or validation, an attacker can provide a path containing .. or symbolic link components that escape the intended directory. When the application later resolves that path on the host file system, it may read or write outside the intended location, leading to unauthorized file access or tampering. Dynamodb itself does not introduce symlink risks, but if your application stores file references (e.g., object keys or local paths) in Dynamodb records and later uses those references in file operations, the stored values can become the vector. For example, a user profile record in Dynamodb might contain an avatar path like uploads/USER_ID/avatar.png; if the service interpolates USER_ID from request parameters without strict validation and constructs a filesystem path, an attacker can manipulate the path traversal. In Feathersjs, this can surface in custom hooks or middleware that perform file reads/writes, especially when integrating with storage adapters that expose local file paths. The risk is not in Dynamodb’s API but in how application code resolves paths before interacting with the file system. An attacker may attempt to read sensitive files (e.g., /etc/passwd) or overwrite configuration files by leveraging insecure path resolution. Because Feathersjs encourages modular services and hooks, it’s important to audit any file-related logic and ensure that path resolution is deterministic and confined to a designated base directory.

To prevent symlink-related issues in a Feathersjs application that uses Dynamodb, focus on strict input validation, canonical paths, and avoiding direct filesystem operations based on user-controlled data. When you must store file references in Dynamodb, keep user input out of path construction or sanitize it rigorously before use.

1. Validate and sanitize user input before using it in file paths

Ensure any identifier used to build a filesystem path is alphanumeric or matches an allowlist, and reject paths containing .., leading slashes, or null bytes. Use a dedicated validation library or simple checks.

// Example: validate userId before building a path
function safeUserId(userId) {
  if (!/^[a-zA-Z0-9_-]+$/.test(userId)) {
    throw new Error('Invalid user identifier');
  }
  return userId;
}

const userId = safeUserId(req.params.userId);
const baseDir = '/var/uploads';
const resolved = path.join(baseDir, userId, 'avatar.png');
// Ensure the resolved path is still under baseDir
if (!resolved.startsWith(path.resolve(baseDir))) {
  throw new Error('Path traversal attempt detected');
}

2. Use path.resolve and path.join to prevent directory traversal

Always resolve user input against a known base directory and verify containment. Do not rely on relative paths when interacting with the filesystem.

const baseDir = path.resolve('/var/uploads');
const userProvided = 'subdir/../etc/passwd';
const target = path.join(baseDir, userProvided);
if (!target.startsWith(baseDir)) {
  throw new Error('Invalid path');
}
// Proceed with fs operations on target

3. Prefer key-based references in Dynamodb instead of filesystem paths

Store only controlled keys in Dynamodb and map them to files server-side within a secured directory. Avoid storing or concatenating raw user input into paths.

// Storing a controlled key in Dynamodb
const putParams = {
  TableName: 'UserProfiles',
  Item: {
    userId: { S: 'user123' },
    avatarKey: { S: 'avatars/user123.png' } // key only, not a filesystem path
  }
};
await dynamodb.send(new PutCommand(putParams));

// Later, when serving the file, map the key to a safe location
function getAvatarPath(key) {
  const safeKey = key.replace(/[^a-zA-Z0-9._/-]/g, '');
  return path.join(baseDir, safeKey);
}

4. Hooks and services in Feathersjs: centralize file handling

Keep file operations in a single, well-audited service or hook. Do not allow arbitrary path construction in multiple places. Apply the same validation and canonicalization consistently.

// feathers-hooks-common style example
const { iff, isProvider } = require('feathers-hooks-common');
const { discard } = require('feathers-hooks-common');

function safeFileHook(options) {
  return async context => {
    const data = context.data || {};
    const userId = safeUserId(data.userId);
    const baseDir = '/var/uploads';
    const filePath = path.join(baseDir, userId, 'avatar.png');
    if (!filePath.startsWith(path.resolve(baseDir))) {
      throw new Error('Invalid file path');
    }
    // Proceed with fs operations using filePath
    context.data.filePath = filePath;
    return context;
  };
}

// Apply in a Feathers service
app.service('profiles').hooks({
  before: {
    create: [iff(isProvider('external'), safeFileHook({}))]
  }
});

5. Secure file reads/writes and avoid exposing internal paths

When using filesystem operations, open files by resolved path and never expose internal paths in API responses. Use streams for large files and ensure permissions restrict access to the intended directories.

const fs = require('fs');
function sendFile(filePath, res) {
  const resolved = path.resolve(filePath);
  if (!resolved.startsWith(path.resolve('/var/uploads'))) {
    res.status(400).send('Invalid file');
    return;
  }
  fs.createReadStream(resolved).pipe(res);
}

6. Consider middleware for path normalization and logging

Add lightweight middleware in Feathersjs to log and normalize path inputs for auditability. This complements runtime checks and helps detect probing behavior early.

app.use('/files', (req, res, next) => {
  const normalized = path.normalize(req.query.path || '');
  if (normalized.includes('..')) {
    return res.status(400).send('Invalid path');
  }
  next();
});

By combining these practices—strict input validation, canonical path resolution, centralizing file logic, and avoiding direct exposure of internal paths—you reduce the risk of symlink attacks when integrating Feathersjs with Dynamodb. Remember that Dynamodb remains a secure data store; the mitigations focus on how application code handles paths and files derived from user input.