Open Redirect in Fiber with Dynamodb

An Open Redirect in a Fiber application that uses DynamoDB as a backend data store can occur when an endpoint accepts a user-supplied URL or location parameter and uses data from DynamoDB to decide where to redirect. If the DynamoDB item influences the redirect target—for example, a user record stores a post-login return URL and the application redirects to that value without validation—an attacker can craft a URL that causes the app to redirect to a malicious site. This typically happens when the application trusts the DynamoDB value and does not enforce strict allowlists or canonicalization before issuing the redirect.

From a scanning perspective, middleBrick tests unauthenticated endpoints that accept identifiers (e.g., a user ID or alias) and perform a DynamoDB lookup. If the response is then used in a Location header or an HTML meta refresh without strict validation, middleBrick flags this as an Open Redirect. The scan does not require credentials; it submits the endpoint with a user identifier, inspects the response for a redirect, and checks whether the redirect target can be controlled via DynamoDB-stored data. Attack patterns such as OAuth post-login redirects or password-reset flows are common real-world scenarios where this vector appears.

An example scenario: a GET endpoint /welcome?user_id=123 queries DynamoDB for user preferences that include a redirect_url field, and the server responds with a 302 to that URL. If an attacker registers or updates their DynamoDB item to contain https://evil.example.com, the next time the victim visits /welcome?user_id=attacker_id they are sent to the attacker’s site. middleBrick would detect the missing referrer checks, missing allowlist validation, and the presence of a user-controlled Location header sourced from DynamoDB.

Remediation focuses on ensuring that any redirect target sourced from DynamoDB is validated, normalized, and restricted to safe destinations. Do not trust raw values stored in DynamoDB; treat them as untrusted input. Use allowlists for known safe domains or enforce internal-only paths. Below are concrete Fiber handlers with proper DynamoDB retrieval and safe redirect practices.

Example 1: Safe redirect with allowlist validation

const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const { unmarshall } = require('@aws-sdk/util-dynamodb');
const { app, get } = require('express')(); // using express-like Fiber pattern

const client = new DynamoDBClient({ region: 'us-east-1' });

async function getRedirectUrl(userId) {
  const cmd = new GetItemCommand({
    TableName: process.env.USER_TABLE,
    Key: { user_id: { S: userId } },
  });
  const resp = await client.send(cmd);
  if (!resp.Item) return null;
  const data = unmarshall(resp.Item);
  return data.redirect_url; // value from DynamoDB
}

get('/welcome', async (req, res) => {
  const userId = req.query.user_id;
  const target = await getRedirectUrl(userId);
  if (!target) return res.status(400).send('Missing user data');

  // Strict allowlist: only internal hostnames
  const allowed = new Set(['https://app.example.com/dashboard', 'https://app.example.com/home']);
  if (!allowed.has(target)) {
    return res.status(400).send('Invalid redirect target');
  }

  res.redirect(target);
});

Example 2: Path-only redirect (no external domains)

const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const { unmarshall } = require('@aws-sdk/util-dynamodb');

async function getPagePath(userId) {
  const cmd = new GetItemCommand({
    TableName: 'pages',
    Key: { user_id: { S: userId } },
  });
  const resp = await client.send(cmd);
  if (!resp.Item) return null;
  return unmarshall(resp.Item).page_path; // e.g., '/settings'
}

app.get('/page', async (req, res) => {
  const path = await getPagePath(req.query.user_id);
  if (!path || !path.startsWith('/')) {
    return res.status(400).send('Invalid page');
  }
  // Ensure no newlines or fragments that could break redirects
  if (path.includes('\n') || path.includes('\r')) {
    return res.status(400).send('Invalid path');
  }
  res.redirect(302, path);
});

General best practices

• Never use raw Location values from DynamoDB without allowlist checks or strict pattern validation (e.g., only relative paths or specific hostnames).
• Normalize and canonicalize any URL inputs before storing them in DynamoDB and before using them in redirects.
• Log suspicious redirect attempts and monitor DynamoDB attribute updates that change redirect_url fields.
• Apply the same validation to meta refresh or JavaScript-based redirects as you do to HTTP Location headers.

middleBrick scans help identify these patterns by correlating DynamoDB access patterns with redirect behavior in the runtime scan, providing prioritized findings and remediation guidance without requiring credentials or agents.