Dangling Dns in Flask (Python)

In a Flask application that makes outbound HTTP requests — such as calling an external API for payments, notifications, or data enrichment — a dangling DNS vulnerability can emerge when the application constructs request URLs using unsanitized or dynamically generated hostnames. This is especially risky in Flask apps that rely on Python string formatting or template engines to build endpoints from user-controllable inputs, environment variables, or configuration files.

For example, consider a Flask route that processes a user-provided callback URL for webhook validation:

<pre>
@app.route('/webhook', methods=['POST'])
def webhook():
    callback_url = request.args.get('callback')  # User-supplied URL
    response = requests.get(callback_url)  # Outbound request to user-controlled domain
    return 'OK', 200
</pre>
If the application does not validate that callback_url resolves to an allowed domain, an attacker can supply a hostname that points to a DNS-controlled server they control. This is a dangling DNS scenario: the application trusts the DNS resolution process, but the resolved IP may point to an unexpected or malicious host. In Flask, this risk is amplified when using Python's socket.gethostbyname() or similar low-level resolution without timeouts or integrity checks.
Flask itself does not enforce DNS safety — it is the developer’s responsibility to validate or restrict outbound destinations. Without proper input sanitization or allowlists, the app may issue HTTP requests to attacker-controlled domains, leading to data exfiltration, SSRF, or credential leakage. This pattern is common in microservices that accept webhook URLs from third parties without rigorous validation.
Additionally, Flask apps often load configuration from environment variables or JSON files that may contain hostnames used in background tasks. If these are interpolated directly into request URLs without validation, they become vectors for dangling DNS attacks. The vulnerability is not inherent to Flask or Python, but to how developers handle dynamic host resolution in a black-box scanning context.
middleBrick detects such risks by analyzing the application’s request patterns, including outbound URL construction, and correlating them with DNS resolution behavior. During a scan, it flags endpoints that accept host-controllable parameters and perform external HTTP calls, especially when no allowlist or validation logic is evident in the codebase.

To mitigate dangling DNS risks in Flask applications, developers must ensure that any user-controllable or dynamically generated hostname used in outbound requests is validated against a strict allowlist or sanitized before use. One effective approach is to parse the URL and verify the hostname against a predefined list of trusted domains.

Here is a secure implementation using Python’s urllib.parse and socket modules:

<pre>
import requests
from urllib.parse import urlparse

TRUSTED_HOSTS = {'api.paymentgateway.com', 'notifications.example.com'}

@app.route('/webhook', methods=['POST'])
def webhook():
    callback_url = request.args.get('callback')
    if not callback_url:
        return 'Missing callback', 400

    parsed = urlparse(callback_url)
    if parsed.scheme not in {'http', 'https'}:
        return 'Invalid scheme', 400

    # Ensure hostname is trusted
    if parsed.hostname not in TRUSTED_HOSTS:
        return 'Untrusted host', 403

    # Optional: perform DNS resolution with timeout
    try:
        socket.gethostbyname(parsed.hostname)
    except socket.gaierror:
        return 'DNS resolution failed', 400

    try:
        response = requests.get(callback_url, timeout=5)
        return 'OK', 200
    except requests.RequestException as e:
        return f'Request failed: {str(e)}', 500
</pre>
This code ensures that only hostnames in TRUSTED_HOSTS are accepted, preventing arbitrary DNS resolution. Additionally, it uses socket.gethostbyname() with proper error handling to avoid hanging on malformed or non-resolving domains.
For more complex scenarios, consider using DNS resolution with timeout enforcement via dnspython or validating the resolved IP against a known list of authorized IPs. Always avoid direct string interpolation of user input into request URLs.
middleBrick can identify such patterns during scanning and recommend allowlist-based validation as a remediation path, helping teams reduce exposure to dangling DNS attacks in Flask-based services.