Bleichenbacher Attack in Django with Bearer Tokens

A Bleichenbacher attack is a cryptographic padding oracle exploit first described in the context of RSA PKCS#1 v1.5. In Django, this pattern can manifest when an API endpoint accepts a Bearer token and performs decryption or signature verification with error messages that differ meaningfully between padding failures, MAC failures, or other cryptographic validation steps. If the server returns distinct HTTP status codes or response content for padding errors versus other failures, an attacker can iteratively decrypt or forge a Bearer token by observing these timing or behavioral differences.

In a typical API flow, a client sends Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.... If the server uses a token format that relies on RSA-based JWT verification with PKCS#1 padding and does not use constant-time verification, a Bleichenbacher-style oracle may be reachable without authentication. For example, an endpoint that decodes the header and payload but does not validate the signature correctly can expose padding errors through timing or error messages. Even when tokens are expected to be opaque, if the backend performs cryptographic operations on them (e.g., decrypting a JWE or verifying an RSA-based JWS), the server’s behavior can become an oracle for an attacker who can send many crafted Bearer tokens and observe responses.

Django REST Framework (DRF) and Django’s own cryptographic utilities do not introduce this vulnerability directly; the risk arises from how tokens are validated. If a view accepts a Bearer token and calls functions that perform RSA decryption or verification with non-constant-time checks, an attacker can mount a Bleichenbacher attack by sending modified tokens and measuring response differences. Common indicators include varied HTTP 401/403 messages, different response times, or distinct error payloads for padding failures. This is especially relevant when the API uses libraries that do not enforce strict padding validation or when developers inadvertently expose low-level verification errors. The unauthenticated attack surface emphasized by middleBrick’s checks can surface such endpoints during scans, highlighting places where cryptographic validation logic must be hardened.

To illustrate, consider a Django view that decodes a JWT signed with RS256 using PyJWT. If the verification step does not use options={"verify_signature": true} consistently and instead falls back to manual checks, padding errors from the RSA operation may leak. An attacker can automate requests with slightly altered ciphertexts in the Bearer token, collecting timing or error-response data to gradually recover the plaintext or forge tokens. This demonstrates why cryptographic operations in token validation must be implemented and configured to avoid distinguishable failure paths, regardless of whether the token is an opaque string or a structured JWT.

Remediation centers on ensuring that all cryptographic validation steps for Bearer tokens execute in constant time and return uniform error responses. In Django, this means standardizing error handling for token validation and avoiding any code paths that expose padding or signature verification differences.

Example 1: Secure JWT verification with PyJWT in a Django view

import jwt
from django.http import JsonResponse
from django.views import View

class ProtectedApiView(View):
    def post(self, request):
        auth = request.headers.get('Authorization', '')
        if not auth.startswith('Bearer '):
            return JsonResponse({'error': 'invalid_token'}, status=401)
        token = auth.split(' ', 1)[1]
        try:
            # Always verify signature explicitly and use constant-time algorithms
            payload = jwt.decode(
                token,
                key='',
                algorithms=['RS256'],
                options={'verify_signature': True, 'require': ['exp', 'iss']}
            )
            # Process payload safely
            return JsonResponse({'data': 'success'})
        except jwt.InvalidTokenError:
            # Use a single, generic error path to avoid oracle behavior
            return JsonResponse({'error': 'invalid_token'}, status=401)

Example 2: Enforcing constant-time comparison for opaque Bearer tokens

import hmac
import hashlib
from django.http import JsonResponse
from django.views import View

class OpaqueTokenView(View):
    def post(self, request):
        auth = request.headers.get('Authorization', '')
        if not auth.startswith('Bearer '):
            return JsonResponse({'error': 'invalid_token'}, status=401)
        token = auth.split(' ', 1)[1]
        # Compare against a stored token using HMAC to avoid timing leaks
        expected = 'stored_token_value'
        if not hmac.compare_digest(token, expected):
            return JsonResponse({'error': 'invalid_token'}, status=401)
        return JsonResponse({'data': 'authorized'})

Example 3: DRF view with consistent error handling

from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
import jwt

class SecureTokenView(APIView):
    def get(self, request):
        auth = request.headers.get('Authorization', '')
        if not auth.lower().startswith('bearer '):
            return Response({'detail': 'Authentication failed.'}, status=status.HTTP_401_UNAUTHORIZED)
        token = auth.split(' ', 1)[1]
        try:
            # Use PyJWT with constant-time verification and strict options
            payload = jwt.decode(
                token,
                key='',
                algorithms=['RS256'],
                options={'verify_signature': True}
            )
            return Response({'scope': payload.get('scope')})
        except jwt.ExpiredSignatureError:
            return Response({'detail': 'Token expired.'}, status=status.HTTP_401_UNAUTHORIZED)
        except jwt.InvalidTokenError:
            # Always return the same status and generic message
            return Response({'detail': 'Authentication failed.'}, status=status.HTTP_401_UNAUTHORIZED)

Operational recommendations

• Always verify signatures explicitly and avoid fallback modes that skip validation.
• Use libraries and functions that run cryptographic checks in constant time (e.g., hmac.compare_digest for comparisons).
• Return a single, generic error response for all token validation failures to eliminate observable differences.
• If using JWE or encrypted tokens, ensure decryption routines do not expose padding or decryption errors as distinguishable responses.
• Regularly scan APIs with tools like middleBrick to detect endpoints that process Bearer tokens and check whether they expose unauthenticated attack surfaces.