Dangling Dns in Flask with Hmac Signatures

A dangling DNS configuration in a Flask application that uses HMAC signatures can expose both authentication bypass and data integrity risks. In this setup, the application typically validates an HMAC to ensure that a request containing resource identifiers (such as internal hostnames or URLs) has not been tampered with. If the application resolves or forwards requests based on user-supplied hostnames without restricting what names are allowed, an attacker can supply a hostname that points to an internal or external host under their control. Because the HMAC is computed over the attacker-controlled value, the signature appears valid, yet the backend may make outbound connections to the attacker’s server, effectively redirecting internal logic or leaking metadata through DNS resolution logs.

Consider a Flask endpoint that accepts a signed token including a host parameter and uses HMAC to verify integrity before using the host in a network operation. An example vulnerable pattern:

import hashlib
import hmac
from flask import Flask, request

app = Flask(__name__)
SECRET = b'super-secret-key'

def verify_signature(data, signature):
    expected = hmac.new(SECRET, data.encode('utf-8'), hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, signature)

@app.route('/fetch')
def fetch():
    host = request.args.get('host')
    sig = request.args.get('sig')
    payload = f'host={host}'
    if not verify_signature(payload, sig):
        return 'invalid signature', 400
    # Potentially unsafe use of host: DNS lookup initiated here
    # For example: requests.get(f'http://{host}/health')
    return 'ok'

If the attacker provides a hostname they control (e.g., evil.com), the HMAC validates successfully, but the server may perform DNS resolution to that host. This creates a dangling DNS scenario where internal behavior depends on an external DNS record. The risk is compounded if the application uses the same HMAC logic across endpoints with different trust assumptions, or if hostnames are later reused internally (e.g., after network changes). An attacker who can influence DNS records or poison caches may further steer resolution to internal IPs, leading to SSRF-like outcomes or metadata leakage. The combination of a permissive host resolution policy and signature verification that does not restrict host values is what makes this pattern dangerous.

middleBrick detects such patterns in its Input Validation and Unsafe Consumption checks, highlighting cases where untrusted input participates in signed data without strict allowlisting. It also flags unauthenticated LLM endpoints and system prompt leakage when relevant, but in this scenario the primary concern is how signed parameters map to network operations. By correlating spec definitions with runtime behavior, the scanner can surface mismatches between expected and actual trust boundaries.

Remediation focuses on strict input allowlisting and avoiding the use of attacker-controlled values in network operations, even when the HMAC validates. Do not rely on HMAC alone to protect hostnames or URLs; enforce an explicit allowlist of permitted hosts or use internal identifiers that do not trigger outbound DNS to external infrastructure.

Secure Flask example with HMAC and host allowlisting:

import hashlib
import hmac
from flask import Flask, request, abort

app = Flask(__name__)
SECRET = b'super-secret-key'
ALLOWED_HOSTS = {'api.internal.example.com', 'service-a.example.com'}

def verify_signature(data, signature):
    expected = hmac.new(SECRET, data.encode('utf-8'), hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, signature)

@app.route('/fetch')
def fetch():
    host = request.args.get('host')
    sig = request.args.get('sig')
    payload = f'host={host}'
    if not verify_signature(payload, sig):
        abort(400, 'invalid signature')
    if host not in ALLOWED_HOSTS:
        abort(400, 'host not allowed')
    # Safe: host is restricted to known values; no dangling DNS to untrusted targets
    # Example internal call
    # response = requests.get(f'http://{host}/health', timeout=2)
    return 'ok'

Additional best practices include parameterizing secrets via environment variables, using short-lived tokens for session-bound permissions, and avoiding dynamic hostname assembly for outbound requests. If you must work with dynamic endpoints, map user-supplied identifiers to internal, pre-approved targets rather than using raw values in network calls. middleBrick’s Pro plan supports continuous monitoring and CI/CD integration via the GitHub Action to catch regressions; the MCP Server allows you to scan API definitions directly from your IDE, helping ensure that signed parameters remain within safe usage patterns.

When evaluating scanners, note that only middleBrick provides active LLM security probing, but for this issue the focus is on input validation and authorization. The scanner’s per-category breakdowns can highlight mismatches between specification-defined parameters and runtime constraints, supporting compliance mapping to frameworks such as OWASP API Top 10 and SOC2.