Formula Injection in Django with Hmac Signatures

Formula Injection occurs when an attacker can control part of a computed value that is later used in a security-sensitive operation. In Django, combining signed values with HMAC-based signatures can introduce risks if the data used to generate or verify the signature is derived from or influenced by attacker-controlled input. This typically happens when a developer includes user-supplied data in the material that is hashed with a secret key to produce an HMAC, or when the application verifies a signature and then uses the signed payload in a way that affects behavior, such as selecting a database identifier or constructing a redirect URL.

Consider a scenario where a Django view builds a signed token that includes a numeric object identifier, for example object_id, and includes that identifier in the data that is HMAC-signed. If the view then, upon verifying the signature, directly uses object_id to fetch an object without additional authorization checks, the signed value becomes an indirect trust boundary. An attacker who cannot forge the HMAC may still manipulate the signed payload if the application embeds user input into the signed material in an unsafe way, or if the signature is computed over a string that includes user-controlled components without canonicalization. For instance, if the signature is generated over concatenated strings like f'{object_id}:{expiry}' and object_id is supplied by the client (e.g., via query parameters), tampering with object_id changes the signed string, so the signature would no longer match unless the attacker knows the secret. However, if the application mistakenly treats the signature as proof of integrity for the entire set of parameters and does not re-validate business-level permissions, the signed parameter may be abused in a BOLA/IDOR context.

Another pattern involves using HMAC signatures to protect state in password reset or email confirmation flows. If the signed payload includes a user identifier and a timestamp, and the application uses the signature to ensure the payload has not been altered, an attacker might exploit weak handling of the verified data. For example, if after signature verification the code performs an operation like User.objects.get(id=signed_data['user_id']) without confirming that the authenticated user is allowed to act on that ID, the signed token enforces integrity but not authorization. This is a Formula Injection vector because the signed formula (how the token is built and interpreted) allows an attacker to influence which resource is accessed by changing values within the signed payload, provided the application does not enforce ownership checks.

In the context of Django, developers might use django.core.signing or implement custom HMAC verification with hmac.compare_digest. The risk arises not from HMAC itself, which is a secure construct when used with a strong key and canonical inputs, but from how the signed values are constructed, serialized, and consumed. Common pitfalls include including non-validated user input in the signed string, failing to bind the signed value to a specific scope (such as the current user or session), and not enforcing rate limits or replay protections on signed endpoints. These issues align with broader API security concerns such as BOLA/IDOR and Injection, and they demonstrate why signed data must be treated as opaque and validated against business rules rather than trusted solely because it carries a valid HMAC.

To mitigate Formula Injection risks when using HMAC signatures in Django, ensure that signed values are constructed from canonical, server-controlled data, that signatures are verified with constant-time comparison, and that verified data is re-validated against authorization checks before use. Below are concrete patterns and code examples demonstrating secure practices.

1. Use server-side identifiers and avoid embedding user-controlled data in the signed material. Sign only a minimal, canonical set of values such as a numeric ID, a fixed context label, and an expiry timestamp. Deserialize and validate each field after verification.

import hmac
import hashlib
import time
from django.conf import settings

def generate_hmac_token(user_id):
    timestamp = int(time.time()) + 3600  # 1 hour expiry
    message = f'{user_id}:{timestamp}'
    signature = hmac.new(
        settings.SECRET_KEY.encode('utf-8'),
        msg=message.encode('utf-8'),
        digestmod=hashlib.sha256
    ).hexdigest()
    return f'{user_id}:{timestamp}:{signature}'

def verify_hmac_token(token):
    try:
        user_id_str, timestamp_str, signature = token.split(':')
        user_id = int(user_id_str)
        timestamp = int(timestamp_str)
        if timestamp < int(time.time()):
            return None  # expired
        message = f'{user_id_str}:{timestamp_str}'
        expected = hmac.new(
            settings.SECRET_KEY.encode('utf-8'),
            msg=message.encode('utf-8'),
            digestmod=hashlib.sha256
        ).hexdigest()
        if not hmac.compare_digest(signature, expected):
            return None
        # Re-validate business permissions here
        return user_id
    except (ValueError, TypeError):
        return None

2. Bind the signed payload to the current user or session context. After verifying the signature, confirm that the user associated with the request is authorized to act on the resource identified by the signed data. This prevents BOLA even if an attacker can manipulate signed values within allowed formats.

from django.http import HttpRequest, JsonResponse
from django.views.decorators.http import require_http_methods

@require_http_methods(["GET"])
def access_limited_resource(request: HttpRequest, token: str) -> JsonResponse:
    user_id = verify_hmac_token(token)
    if user_id is None:
        return JsonResponse({'error': 'invalid token'}, status=400)
    # Ensure the token refers to the requesting user
    if user_id != request.user.id:
        return JsonResponse({'error': 'forbidden'}, status=403)
    # Proceed with safe, authorized operations
    return JsonResponse({'data': 'secure resource'})

3. Use Django’s signing utilities with strict serialization and avoid unsafe string concatenation. Prefer JSON serialization with sorted keys to ensure canonical representation, and validate types after verification.

import json
import hmac
import hashlib
import time
from django.core.signing import BadSignature, SignatureExpired, TimestampSigner

def secure_sign(data: dict, secret: str, expiry: int = 3600) -> str:
    signer = TimestampSigner(key=secret, salt='api-token')
    payload = json.dumps(data, sort_keys=True, separators=(',', ':'))
    return signer.sign(payload) + f'.{int(time.time())}'

def secure_verify(token: str, secret: str, expiry: int = 3600) -> dict:
    try:
        signer = TimestampSigner(key=secret, salt='api-token')
        payload, timestamp = token.rsplit('.', 1)
        unsigned = signer.unsign(payload, max_age=expiry)
        return json.loads(unsigned)
    except (BadSignature, SignatureExpired, ValueError):
        return {}

4. Apply defense-in-depth measures such as rate limiting and replay prevention. Even when signatures are verified, ensure that each signed request is processed at most once within a relevant window and that tokens are single-use or strictly time-bound for sensitive operations.

By canonicalizing inputs, validating server-side identifiers, and enforcing authorization after signature verification, you reduce the risk of Formula Injection while still leveraging HMACs for integrity.