Open Redirect in Restify with Hmac Signatures

An open redirect in a Restify service that uses Hmac Signatures can occur when query parameters or headers that influence the redirect target are not validated, even though the request is authenticated with an Hmac signature. The signature may verify that the request originates from a trusted source, but it does not inherently validate the semantics of the request, such as the destination URL. If the endpoint accepts a next, redirect_to, or similar parameter and uses it directly in a response redirect (e.g., 302), an attacker can supply a malicious external URL while still providing a valid Hmac-signed request.

Because Hmac Signatures typically bind the request body, method, and selected headers to prevent tampering, developers may assume that the request itself is trusted. However, if the redirect target is derived from user-controlled input and not checked against a strict allowlist or validated as relative, the signed request can be weaponized for phishing or client-side abuse. The signature does not protect against logic flaws where the application intentionally follows a user-supplied URL, even when that URL points to an attacker-controlled domain.

In the context of the 12 security checks run by middleBrick, this pattern maps to the BOLA/IDOR and Property Authorization checks, where authorization is evaluated on resource ownership or action permissions rather than on the trustworthiness of redirect targets. An unauthenticated scan or an authenticated-style scan that does not validate redirect rules may flag this as a potential open redirect despite the presence of Hmac Signatures. Attackers can combine signed requests crafted via compromised or misconfigured client credentials with open redirect parameters to build convincing phishing chains that retain the integrity of the signature.

Real-world examples include integrations where a Restify endpoint accepts a signed payload with a returnUrl field and then performs res.redirect(returnUrl) without ensuring the URL is relative or belongs to a permitted host. This can lead to account takeover support scenarios where users are tricked into clicking a signed link that redirects them to a malicious site mimicking the original service.

middleBrick scans this attack surface by checking whether redirect parameters are constrained and whether signature validation is coupled with strict destination validation. The tool examines the unauthenticated attack surface and, when an OpenAPI specification is provided, cross-references defined parameters and security schemes with runtime behavior to highlight mismatches between authentication and authorization logic.

To remediate open redirect vulnerabilities in Restify when using Hmac Signatures, you must enforce strict validation of redirect targets independently of signature verification. Signature validation should confirm integrity and origin, but it should never implicitly trust user-supplied redirect destinations. Always treat redirect targets as untrusted input and apply allowlisting or path-relative checks before performing any redirect.

Below are concrete Restify code examples that demonstrate secure handling. The first example shows an unsafe implementation that is vulnerable despite using Hmac validation, followed by a corrected version that mitigates the open redirect risk.

// Unsafe example — do not use
const crypto = require('crypto');
const restify = require('restify');

function verifyHmac(req) {
  const signature = req.headers['x-hmac-signature'];
  const body = req.rawBody;
  const expected = crypto.createHmac('sha256', 'secret').update(body).digest('hex');
  return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

restify.createServer().post('/oauth/callback', (req, res, next) => {
  if (!verifyHmac(req)) {
    return res.send(401, { error: 'invalid_signature' });
  }
  const redirectTo = req.query.next; // user-controlled, not validated
  if (redirectTo) {
    return res.redirect(redirectTo); // open redirect
  }
  res.redirect('/dashboard');
  return next();
});

In the unsafe example, the Hmac signature is verified, but req.query.next is used directly in res.redirect. An attacker can supply https://evil.com as next while providing a valid Hmac signature if the request body and headers are predictable or if a token is leaked.

// Secure example — recommended pattern
const crypto = require('crypto');
const restify = require('restify');

function verifyHmac(req) {
  const signature = req.headers['x-hmac-signature'];
  const body = req.rawBody;
  const expected = crypto.createHmac('sha256', 'secret').update(body).digest('hex');
  return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));
}

function isRelativeOrAllowedUrl(url, allowedHosts) {
  try {
    const parsed = new URL(url, `https://${req.headers.host}`);
    if (!parsed.pathname.startsWith('/')) return false;
    if (allowedHosts && !allowedHosts.includes(parsed.hostname)) return false;
    return true;
  } catch (err) {
    return false;
  }
}

restify.createServer().post('/oauth/callback', (req, res, next) => {
  if (!verifyHmac(req)) {
    return res.send(401, { error: 'invalid_signature' });
  }
  const redirectTo = req.query.next;
  const allowedHosts = ['app.example.com', 'app.staging.example.com'];
  if (redirectTo && isRelativeOrAllowedUrl(redirectTo, allowedHosts)) {
    return res.redirect(redirectTo);
  }
  // Fallback to a safe default
  res.redirect('/dashboard');
  return next();
});

In the secure pattern, isRelativeOrAllowedUrl ensures that redirectTo is either a relative path or points to a host explicitly permitted by an allowlist. This check is performed after Hmac signature validation, ensuring that both integrity and destination safety are enforced. By decoupling authentication from authorization of the redirect target, you eliminate the open redirect while retaining the benefits of Hmac Signatures for request integrity.

When using middleware or helper libraries, apply the same principle: validate the final resolved URL against a strict rule before invoking res.redirect. This approach aligns with secure coding practices for OAuth callbacks and deep-link flows in Restify services.

• Does Hmac Signing alone prevent open redirects in Restify?

  No. Hmac Signatures ensure request integrity and authenticity but do not validate the semantics of user-controlled fields such as redirect targets. You must explicitly validate and restrict redirect destinations regardless of signature verification.

• Can middleBrick detect this misconfiguration during a scan?

  Yes. middleBrick checks for open redirects and evaluates whether authenticated or signed endpoints properly constrain user-supplied redirect parameters. When an OpenAPI spec is provided, it cross-references security schemes with runtime behavior to surface mismatches.