Dns Cache Poisoning in Flask

DNS cache poisoning (also known as DNS spoofing) occurs when an attacker injects false DNS records into a resolver's cache, causing clients to resolve legitimate domain names to malicious IP addresses. In Flask applications, this vulnerability typically manifests when the application makes outbound HTTP requests to external services using domain names that an attacker has poisoned, rather than through direct inbound requests to the Flask server itself.

Flask-specific code patterns that enable DNS cache poisoning exploitation include:

• Using requests or urllib to call external APIs based on user-controlled input without proper validation:

# Vulnerable: user input directly used in external request domain
@app.route('/fetch-image')
def fetch_image():
    image_url = request.args.get('url', '')  # e.g., 'http://evil.com/image.jpg'
    # If DNS cache for 'evil.com' is poisoned to point to internal IP, SSRF may occur
    response = requests.get(image_url)  # No validation of hostname
    return response.content

• Constructing redirect URLs from user input where the domain is not validated:

# Vulnerable: open redirect via poisoned DNS
@app.route('/redirect')
def redirect_user():
    target = request.args.get('target')
    # Attacker poisons DNS for 'trusted-site.com' to point to malicious server
    # User sees 'trusted-site.com' in link but goes to attacker's IP
    return redirect(target, code=302)

• Using service discovery or configuration values that resolve external domains without DNS security controls:

# Vulnerable: hardcoded service name that relies on DNS
import os
PAYMENT_SERVICE_HOST = os.getenv('PAYMENT_SERVICE_HOST', 'payment.internal')
# If attacker poisons DNS for 'payment.internal', requests go to malicious host
payment_url = f'http://{PAYMENT_SERVICE_HOST}/process'
requests.post(payment_url, json=payment_data)

The risk is amplified in Flask apps that:

• Act as proxies or gateways to internal services
• Fetch resources based on user-provided URLs (image fetchers, webhook validators, OEmbed consumers)
• Use service meshes or microservice architectures where inter-service communication relies on DNS
• Lack egress filtering or DNSSEC validation in their deployment environment

Attackers exploit this by poisoning DNS caches via techniques like Kaminsky-style attacks (predicting transaction IDs) or exploiting misconfigured resolvers. Once poisoned, any Flask app making outbound requests to the compromised domain will unknowingly communicate with attacker-controlled infrastructure, potentially leading to SSRF, data exfiltration, or credential theft.

Detecting DNS cache poisoning risk in Flask applications requires identifying patterns where domain names used in outbound connections are influenced by user input or external configuration without adequate validation. Since DNS cache poisoning is an infrastructure-level attack, middleBrick does not detect the poisoning event itself but identifies Flask applications that are vulnerable to exploitation if DNS cache poisoning occurs.

middleBrick’s black-box scanning approach tests the unauthenticated attack surface by analyzing how the Flask endpoint handles input that could be used to construct malicious outbound requests. It looks for:

• Endpoints that accept URL or domain parameters and make HTTP requests to them
• Lack of hostname validation, allowlisting, or schema enforcement
• Potential for SSRF that could be leveraged via poisoned DNS

For example, when scanning a Flask endpoint like:

@app.route('/webhook')
def incoming_webhook():
    callback_url = request.json.get('callback_url')
    # No validation - if DNS for domain in callback_url is poisoned, SSRF occurs
    requests.post(callback_url, json={'status': 'received'})
    return '', 202

middleBrick will:

Identify the endpoint accepts user-controlled input (callback_url)

Detect that this input is used in an outbound HTTP request
Flag missing validation (no check for allowed domains, schemas, or IP ranges)
Correlate this with the Input Validation and SSRF security checks in its 12-check suite
Provide a finding with severity based on exploitability and potential impact (e.g., access to internal metadata services)

The scan does not require agents, configuration, or credentials — only the public URL of the Flask application. It takes 5–15 seconds and returns a risk score (A–F) with detailed findings. For DNS cache poisoning exposure, middleBrick will highlight:

Missing URL schema validation (allowing http:// or https:// only)
Absence of hostname allowlisting or blocklisting (e.g., rejecting localhost, private IP ranges)
No use of urlparse to extract and validate netloc before making requests
This enables developers to understand that their Flask application is susceptible to DNS cache poisoning–based SSRF and implement controls at the application layer, independent of network-level DNS security.