Request Smuggling in Django with Basic Auth

Request smuggling occurs when an application processes HTTP requests differently depending on whether they are interpreted as front-end or back-end requests. In Django, this can arise when USE_X_FORWARDED_HOST or USE_X_FORWARDED_PORT is enabled behind a proxy, and the service also enforces HTTP Basic Authentication at the proxy or application layer. When authentication is handled primarily by the proxy using Basic Auth headers, Django may construct URLs and redirect locations using host information it receives from headers such as Host, X-Forwarded-Host, or X-Forwarded-Proto. If header ordering and parsing are not strictly consistent, an attacker can craft requests where the smuggled request uses a different host or port context, causing the front-end and back-end to interpret the request boundary differently.

With Basic Auth, the credentials are sent in the Authorization header. If a Django instance behind a load balancer or API gateway parses the request line and headers inconsistently—such as when the proxy terminates TLS and forwards the request on to Django over HTTP—smuggled requests can bypass intended authentication scopes. For example, an attacker may send a request that contains two Host headers or mixes Content-Length and Transfer-Encoding in a way that causes the proxy to interpret one request and Django to interpret another. Because Basic Auth is validated per request in Django (typically via middleware or decorator), a smuggled request might reach an endpoint without the expected credentials if the host or routing context differs, leading to unauthorized access or data leakage.

This risk is especially relevant when using OpenAPI/Swagger specifications that include securitySchemes with HTTP Basic schemes. The generated client or documentation may assume consistent header handling, but runtime differences in how proxies and Django parse messages can expose endpoints. middleBrick’s scans include checks for insecure header parsing and host validation, flagging cases where X-Forwarded-* usage interacts with authentication headers in ways that could enable request smuggling.

To mitigate request smuggling in Django when using HTTP Basic Authentication, enforce strict header processing and avoid relying on potentially ambiguous headers for routing or authentication decisions. Below are concrete, secure patterns and code examples.

1. Use Django’s built-in HTTP Basic Authentication correctly

Use django.contrib.auth and django.http.Http404 with explicit header parsing rather than relying on proxy-set headers for authentication. Here is a secure view using Basic Auth via the WWW-Authenticate challenge:

import base64
from django.http import HttpResponse, HttpResponseForbidden, HttpResponseBadRequest
from django.views import View

class BasicAuthView(View):
    def authenticate(self, request):
        auth = request.META.get('HTTP_AUTHORIZATION', '')
        if not auth.lower().startswith('basic '):
            return None
        try:
            encoded = auth.split(' ', 1)[1].strip()
            decoded = base64.b64decode(encoded).decode('utf-8')
            username, _, password = decoded.partition(':')
            # Replace with your user verification logic, e.g., Django’s authenticate()
            user = self.validate_user(username, password)
            return user
        except Exception:
            return None

    def validate_user(self, username, password):
        # Example: validate against Django’s user model
        from django.contrib.auth.models import User
        try:
            user = User.objects.get(username=username)
            if user.check_password(password):
                return user
        except User.DoesNotExist:
            pass
        return None

    def handle_no_permission(self):
        response = HttpResponse(status=401)
        response['WWW-Authenticate'] = 'Basic realm="api"'
        return response

    def dispatch(self, request, *args, **kwargs):
        if not request.META.get('HTTP_AUTHORIZATION', '').lower().startswith('basic '):
            return self.handle_no_permission()
        user = self.authenticate(request)
        if user is None:
            return self.handle_no_permission()
        return super().dispatch(request, *args, **kwargs)

2. Disable or strictly limit X-Forwarded-* usage

If your deployment includes a proxy, configure Django to trust the proxy explicitly and avoid using USE_X_FORWARDED_HOST unless necessary. When required, set SECURE_PROXY_SSL_HEADER and validate against a known proxy IP list:

# settings.py
USE_X_FORWARDED_HOST = False
USE_X_FORWARDED_PORT = False
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

# Only allow specific trusted proxy IPs
ALLOWED_HOSTS = ['api.example.com']

3. Normalize the Host header and reject ambiguous requests

Add middleware that validates the Host header and rejects requests with multiple Host values or malformed headers:

from django.utils.deprecation import MiddlewareMixin
from django.http import HttpResponseBadRequest

class HostHeaderValidationMiddleware(MiddlewareMixin):
    def process_request(self, request):
        host_header = request.META.get('HTTP_HOST', '')
        if ',' in host_header or ' ' in host_header:
            return HttpResponseBadRequest('Invalid Host header')
        # Optionally enforce expected host
        allowed_hosts = {'api.example.com'}
        if host_header not in allowed_hosts:
            return HttpResponseBadRequest('Host not allowed')

4. Prefer session or token auth where feasible

For endpoints under your control, consider using token-based authentication (e.g., JWT) or Django session cookies instead of sending credentials in every header. This reduces the attack surface tied to Basic Auth’s repeated transmission of credentials.

5. Scan with middleBrick to detect header parsing and host-related issues

Use the middleBrick CLI to scan your endpoints for risky header handling and host validation problems:

middlebrick scan https://api.example.com

The dashboard and reports can highlight misconfigurations around X-Forwarded-*, missing host validation, and authentication header handling that could enable smuggling.