Open Redirect in Django with Dynamodb

An Open Redirect occurs when an application redirects a user to an arbitrary URL without proper validation, enabling phishing or malware distribution. In Django, an Open Redirect is commonly introduced when a view uses an untrusted parameter (e.g., next) to construct a redirect via HttpResponseRedirect or redirect. When a DynamoDB-backed service is part of the request flow, the risk can compound if DynamoDB data influences which redirect URL is chosen or if query results are used to build redirect targets.

Consider a Django app that stores canonical redirect mappings in DynamoDB (e.g., short-code to destination URL). A view might look up a code from DynamoDB and redirect the user without strict validation of the stored destination. If an attacker can inject a malicious URL into DynamoDB (for example, via a compromised admin action or an exposed data import), every user following that short code is redirected to a harmful site. Even without DynamoDB write access, an Open Redirect may occur if a DynamoDB-stored URL is concatenated with user input (such as a campaign ID) and used in a redirect, and the validation on the combined URL is weak.

Another scenario involves using DynamoDB to decide whether to redirect based on user attributes (e.g., feature flags or tenant settings). If the attribute value is used directly in a redirect without verifying it is a safe, relative path or a known host, an attacker who can read or influence that DynamoDB item may cause an Open Redirect. Because DynamoDB is often treated as a trusted data store, developers might skip output validation for values originating from DynamoDB, inadvertently turning stored data into a vector for client-side attacks.

In a black-box scan, middleBrick tests for Open Redirect by supplying open redirect patterns (absolute, protocol-relative, and hostname-matching) and observing whether the response performs a redirect to a supplied host. When DynamoDB is in the stack, an insecure lookup or merge between DynamoDB data and request parameters increases the likelihood that a reported redirect finding belongs to this specific integration pattern.

To prevent Open Redirect when DynamoDB is involved, treat every URL derived from DynamoDB as untrusted. Validate and normalize redirect targets, prefer relative paths for internal redirects, and avoid concatenating untrusted input into URLs used in HttpResponseRedirect. Below are concrete patterns for safe handling in Django with DynamoDB data.

1. Validate redirect targets against a whitelist of allowed hosts

Always ensure that any URL used in a redirect either is a relative path or belongs to an explicitly allowed host. Use Django’s urlparse to split the URL and compare the netloc against a set of trusted domains.

from urllib.parse import urlparse
from django.http import HttpResponseRedirect, HttpResponseBadRequest
from django.shortcuts import get_object_or_404
import boto3

def redirect_by_code(request, code):
    # Fetch destination from DynamoDB
    dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
    table = dynamodb.Table('redirects')
    item = table.get_item(Key={'code': code}).get('Item')
    if not item:
        return HttpResponseBadRequest('Invalid code')
    
    destination = item.get('url', '')
    parsed = urlparse(destination)
    allowed_hosts = {'app.example.com', 'cdn.example.com'}
    if not parsed.netloc or parsed.netloc not in allowed_hosts:
        return HttpResponseBadRequest('Invalid redirect target')
    
    return HttpResponseRedirect(destination)

2. Use relative paths when possible and resolve them safely

If your DynamoDB entries store relative paths, resolve them against a base URL and avoid using user-controlled strings in the resolution step.

from urllib.parse import urljoin
from django.http import HttpResponseRedirect

def redirect_relative(request, code):
    dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
    table = dynamodb.Table('redirects')
    item = table.get_item(Key={'code': code}).get('Item')
    if not item:
        return HttpResponseBadRequest('Invalid code')
    
    path = item.get('path', '')
    # Ensure path is relative and safe
    if path.startswith('/'):
        return HttpResponseRedirect(urljoin('https://app.example.com', path))
    return HttpResponseBadRequest('Invalid path')

3. Sanitize concatenated URLs that include DynamoDB data

If you build a URL from DynamoDB fields plus request parameters, validate each component and avoid open concatenation that could lead to open redirects.

from urllib.parse import urlparse, urlunparse, urljoin

def safe_redirect(request, code):
    dynamodb = boto3.resource('dynamodb', region_name='us-east-1')
    table = dynamodb.Table('redirects')
    item = table.get_item(Key={'code': code}).get('Item')
    if not item:
        return HttpResponseBadRequest('Invalid code')
    
    base = item.get('base', '/')
    campaign = request.GET.get('campaign', '')
    # Validate campaign is alphanumeric to prevent injection
    if not campaign.isalnum():
        return HttpResponseBadRequest('Invalid campaign')
    
    destination = urljoin(base, campaign)
    parsed = urlparse(destination)
    if not parsed.netloc or parsed.netloc not in {'app.example.com'}:
        return HttpResponseBadRequest('Invalid destination')
    
    return HttpResponseRedirect(destination)

4. Secure DynamoDB access patterns to avoid unintended data exposure

Ensure IAM policies for DynamoDB are scoped tightly and that items used for routing cannot be tampered with by unauthorized roles. Avoid making redirect mappings user-writable unless you validate each write with strict checks and versioning.