Container Escape in Sails with Hmac Signatures

A container escape in Sails when HMAC signatures are used incorrectly arises when an attacker can influence data that is signed and later used to control execution paths or deserialization. HMACs provide integrity, but if the application signs user-controlled inputs and then uses the signature to reconstruct logic or trust boundaries, the signature can be weaponized to escape intended runtime constraints.

In Sails, this often maps to the BFLA/Privilege Escalation category: an attacker can tamper with identifiers (e.g., model IDs) and then present a valid HMAC for the altered value. Because the server verifies the signature without re-authorizing the subject, it may operate on a different object or elevate context. For example, consider a route that signs a JSON Web Token or a serialized record identifier and later uses that token to look up a model instance. If the payload is not re-validated against authorization policies after signature verification, an attacker can substitute one resource identifier for another, leading to unauthorized access or container escape within the application’s security boundary.

Another vector involves unsafe consumption of signed data. If Sails accepts HMAC-protected payloads from external services and directly deserializes or evaluates content based on the signature, an attacker might exploit deserialization paths or prototype pollution to escape the containerized process or access the host filesystem. This intersects with Unsafe Consumption checks: unauthenticated endpoints that consume signed payloads without verifying intent or context can expose dangerous behavior. Because the signature is trusted implicitly, runtime checks that normally prevent over-privileged operations can be bypassed.

SSRF is also relevant when signed URLs or tokens include host or path parameters. An attacker can craft a signed request that directs the server to make internal network calls, effectively using the HMAC to legitimize SSRF attempts. The signature obscures the malicious target, and if the application does not validate the destination against a strict allowlist, the container can be forced to interact with internal services that would otherwise be unreachable.

Inventory Management and Property Authorization checks highlight additional exposure: signed metadata or configuration blobs may contain permissions or roles. If these are not validated independently of the signature, an attacker can modify properties and rely on the HMAC to maintain validity, leading to privilege escalation or data exposure. Data Exposure risks increase when signed payloads leak sensitive fields; encryption alone does not prevent misuse if the application trusts the signed structure without re-checking access controls.

To remediate HMAC-related issues in Sails, ensure that signatures are verified in the correct context and that signed values are never trusted for authorization without additional checks. Always validate the subject of the signature against the current user’s permissions before using it to access resources.

Example 1 — verify HMAC and re-authorize the resource: In a Sails controller, do not rely on the signature alone to identify a record. Compute the HMAC over the record ID using a server-side secret, compare it with the provided signature, and then enforce ownership or role-based access control.

const crypto = require('crypto');

function verifyHmac(input, signature, secret) {
  const expected = crypto.createHmac('sha256', secret).update(input).digest('hex');
  return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature));
}

module.exports = {
  getUserProfile: async function (req, res) {
    const { id, signature } = req.allParams();
    const secret = sails.config.custom.hmacSecret;
    if (!verifyHmac(id, signature, secret)) {
      return res.unauthorized('Invalid signature');
    }
    // Re-authorize: ensure the current user can access this id
    const profile = await User.findOne(id);
    if (!profile || !await sails.helpers.canAccess(req.user, profile)) {
      return res.forbidden('Not authorized');
    }
    return res.ok(profile);
  }
};

Example 2 — sign and validate complex payloads without trusting content: When you need to pass structured data, sign the canonical representation and validate it before use. Do not include sensitive fields in the signed payload if they must remain confidential, and always enforce encryption separately.

const crypto = require('crypto');

function signPayload(payload, secret) {
  const normalized = JSON.stringify({ userId: payload.userId, role: payload.role, exp: payload.exp });
  const signature = crypto.createHmac('sha256', secret).update(normalized).digest('hex');
  return { payload: normalized, signature };
}

function verifyAndAuthorize(payloadInput, signatureInput, secret, currentUser) {
  const normalized = JSON.stringify({ userId: payloadInput.userId, role: payloadInput.role, exp: payloadInput.exp });
  const expected = crypto.createHmac('sha256', secret).update(normalized).digest('hex');
  const isValid = crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signatureInput));
  if (!isValid) throw new Error('Invalid signature');
  if (payloadInput.exp < Date.now()) throw new Error('Token expired');
  // Additional authorization: ensure currentUser matches userId and has required role
  if (currentUser.id !== payloadInput.userId || currentUser.role !== payloadInput.role) {
    throw new Error('Insufficient permissions');
  }
  return true;
}

// Usage in a Sails action
module.exports.createOrder = async function (req, res) {
  const { payload, signature } = req.body;
  try {
    verifyAndAuthorize(payload, signature, sails.config.custom.hmacSecret, req.user);
    const order = await Order.create({ itemId: payload.itemId, quantity: payload.quantity }).fetch();
    return res.ok(order);
  } catch (err) {
    return res.badRequest(err.message);
  }
};

Example 3 — avoid including sensitive material in signed strings and enforce strict validation: Do not place secrets or PII inside the signed content. Treat HMAC as a integrity check, not an encryption mechanism. Combine with encryption for confidentiality and always validate the scope and context of usage.

const crypto = require('crypto');

function createScopedHmac(entityId, userId, nonce, secret) {
  const message = `${entityId}|${userId}|${nonce}|${Date.now() + 300000}`; // 5-minute window
  return crypto.createHmac('sha256', secret).update(message).digest('hex');
}

function validateScopedHmac(entityId, userId, nonce, providedSig, secret) {
  const computed = createScopedHmac(entityId, userId, nonce, secret);
  return crypto.timingSafeEqual(Buffer.from(computed), Buffer.from(providedSig));
}

// In a policy or controller
module.exports.checkScopedRequest = async function (req, res, next) {
  const { entityId, userId, nonce, signature } = req.params;
  if (!validateScopedHmac(entityId, userId, nonce, signature, sails.config.custom.hmacSecret)) {
    return res.unauthorized('Invalid scoped signature');
  }
  // Proceed with additional checks: ensure userId matches request context and entityId is within allowed scope
  return next();
};