Injection Flaws in Restify with Hmac Signatures

Injection flaws in Restify when Hmac Signatures are used arise when user-controlled data is incorporated into the string that is signed or verified without canonicalization and strict validation. For example, if you build the signing string by concatenating headers, a request path, and a JSON body directly from user input, an attacker can manipulate whitespace, parameter ordering, or encoding to change the effective payload while producing a signature that still passes verification in a permissive implementation.

Consider an endpoint that accepts query parameters and a JSON body, then signs a composed message like: method:GET path:/v1/resource query:action=update&id=123 body:{"amount":100,"currency":"USD"}. If the server does not enforce a strict schema, an attacker can add extra parameters (id=123&extra=inject) or alter JSON key ordering, leading to a different canonical representation. Because the signature is tied to the exact string, a lenient verifier might normalize or truncate input in a way that results in signature acceptance for a tampered request, enabling injection or privilege escalation via BOLA/IDOR or unsafe consumption paths.

Insecure deserialization is another relevant injection risk when Restify handlers process signed payloads that are later deserialized without strict type checks. An attacker could embed executable code or nested objects in the signed JSON, and if the server reconstructs objects from the verified payload without schema validation, it may execute unintended logic. This maps to OWASP API Top 10 categories such as Broken Object Level Authorization (BOLA) and Injection, and can be surfaced by middleBrick’s Property Authorization and Unsafe Consumption checks, which correlate signed input handling with runtime behavior to highlight mismatches between declared permissions and actual data flows.

Other attack surfaces include HTTP method smuggling via signature-computed headers and SSRF when signed parameters are used to construct URLs or file paths. Because middleBrick’s scan runs 12 checks in parallel, it tests unauthenticated endpoints that rely on Hmac Signatures and flags inconsistencies between spec-defined signatures and runtime behavior, such as missing input validation or overly permissive regexes that allow evasion.

Real-world patterns seen in the wild include using non-canonical JSON serialization (which changes key order between environments), failing to reject unexpected keys, and not normalizing whitespace in signature computation. These gaps allow attackers to inject malicious parameters or modify resource identifiers, leading to data exposure or unauthorized operations. middleBrick’s LLM/AI Security checks also probe whether signed endpoints inadvertently expose system prompts or allow prompt injection when API metadata is reflected in responses, adding an additional layer of risk for AI-integrated APIs.

To illustrate a typical vulnerable server, the following code shows a Restify service that builds a signing string from raw request components and verifies the signature without canonicalization or strict validation:

const restify = require('restify');
const crypto = require('crypto');

const server = restify.createServer();
const SHARED_SECRET = 'super-secret-key';

function buildSigningString(req) {
  return [
    req.method,
    req.path(),
    'query:' + req.query.toString(),
    'body:' + JSON.stringify(req.body)
  ].join('\n');
}

server.use(restify.plugins.bodyParser());

server.post('/process', (req, res, next) => {
  const expected = buildSigningString(req);
  const hmac = crypto.createHmac('sha256', SHARED_SECRET);
  const digest = 'sha256=' + hmac.update(expected).digest('hex');
  const received = req.headers['authorization']?.replace('Hmac ', '');

  if (digest !== received) {
    return next(new restify.UnauthorizedError('Invalid signature'));
  }

  // Business logic here
  res.send({ status: 'ok' });
  return next();
});

server.listen(8080, () => console.log('Listening'));

This example is vulnerable because req.query.toString() and JSON.stringify(req.body) do not enforce canonical ordering. An attacker can supply id=123 and id=456 or manipulate JSON key order to change the signed string while keeping the signature valid if the server is permissive. middleBrick’s BOLA/IDOR and Input Validation checks are designed to detect such weaknesses by correlating endpoint definitions with runtime mutation patterns.

Remediation focuses on canonicalization, strict validation, and separation of concerns. Always serialize JSON with a deterministic ordering (e.g., sorted keys), normalize whitespace, and reject unexpected fields. Use a schema validator for the body and explicitly define which headers and parameters are included in the signature scope.

Below is a hardened example using fast-json-stable-stringify for deterministic JSON serialization and a strict allowlist for query parameters:

const restify = require('restify');
const crypto = require('crypto');
const stableStringify = require('fast-json-stable-stringify');

const server = restify.createServer();
const SHARED_SECRET = process.env.SHARED_SECRET;

const ALLOWED_QUERY_PARAMS = ['id', 'action'];

function buildSigningString(req) {
  const sortedBody = stableStringify(req.body || {});
  const filteredQuery = Object.keys(req.query)
    .filter(k => ALLOWED_QUERY_PARAMS.includes(k))
    .sort()
    .map(k => `${k}=${req.query[k]}`)
    .join('&');
  return [
    req.method.toUpperCase(),
    req.path(),
    'query:' + filteredQuery,
    'body:' + sortedBody
  ].join('\n');
}

server.use(restify.plugins.bodyParser());

server.post('/process', (req, res, next) => {
  const expected = buildSigningString(req);
  const hmac = crypto.createHmac('sha256', SHARED_SECRET);
  const computed = 'sha256=' + hmac.update(expected).digest('hex');
  const received = req.headers['authorization']?.replace('Hmac ', '');

  if (!received || !crypto.timingSafeEqual(Buffer.from(computed), Buffer.from(received))) {
    return next(new restify.UnauthorizedError('Invalid signature'));
  }

  // Optional: validate body shape with a schema here
  res.send({ status: 'ok' });
  return next();
});

server.listen(8080, () => console.log('Listening'));

Key improvements include deterministic JSON serialization, query parameter allowlisting, and use of crypto.timingSafeEqual to prevent timing attacks. You should also enforce strict schema validation for the request body (for example with Ajv) and reject any keys not explicitly allowed, which aligns with middleBrick’s Property Authorization checks that verify declared permissions against actual validation rules.

For API specifications defined in OpenAPI 2.0/3.0/3.1, ensure the signature scope is documented explicitly (e.g., via extensions like x-signature-scope) so that automated tools like middleBrick can cross-reference spec definitions with runtime behavior. This helps detect mismatches where the spec claims authentication via Hmac Signatures but the implementation does not enforce canonicalization or allow unexpected parameters, which would be flagged as a high-severity finding.

In summary, remediate injection risks with Hmac Signatures in Restify by canonicalizing inputs, using allowlists, applying strict validation, and verifying signatures with constant-time comparisons. These measures reduce the attack surface for injection, BOLA/IDOR, and unsafe consumption findings that middleBrick identifies across its 12 parallel security checks.