Poodle Attack in Flask with Basic Auth

The Poodle attack (CVE-2014-3566) exploits weaknesses in SSL 3.0, particularly the use of predictable initialization vectors in CBC-mode ciphersuites. When a Flask application uses Basic Authentication over SSL 3.0, the protocol’s lack of protection against byte-at-a-time decryption can allow an attacker who can inject or observe ciphertext to recover authentication credentials. In this combination, credentials are encoded but not encrypted with strong modern algorithms; they travel as an Authorization header value protected only by the transport layer.

Flask itself does not implement SSL; it relies on the underlying WSGI server or reverse proxy (for example, serving via Werkzeug’s built-in server in development or behind a TLS-terminating load balancer). If that endpoint is configured to offer SSL 3.0, an attacker on the network can perform a Poodle-style padding oracle attack against the encrypted HTTP payload, including the Basic Auth header. Because Basic Auth sends credentials in an Authorization header like Authorization: Basic dXNlcjpwYXNz, an adversary who can make chosen-ciphertext requests and observe error differences (for example, bad padding vs. bad MAC) can iteratively decrypt the token and obtain the base64-encoded username and password. Even when the token is base64-encoded, the decoded plaintext becomes recoverable, exposing credentials without needing to break the cipher directly.

In practice, this risk arises when legacy or misconfigured servers, load balancers, or reverse proxies still enable SSL 3.0 to support older clients. A Flask application that trusts the transport to provide confidentiality can be vulnerable if an SSL 3.0-capable endpoint is used. Developers might assume that enabling TLS is sufficient, but without explicitly disabling SSL 3.0, the protocol fallback creates a window for Poodle. This is a protocol-level weakness, not a Flask bug, but the framework’s default configurations and common deployment patterns can inadvertently expose Basic Auth to this vector.

middleBrick detects such risks by scanning the unauthenticated attack surface and analyzing the effective TLS configuration presented at the endpoint. It checks for SSL 3.0 support and flags weak ciphersuites that enable padding oracle attacks, including those that could compromise Basic Auth tokens. The scan also reviews OpenAPI/Swagger specifications (with full $ref resolution) and runtime behavior to correlate protocol weaknesses with exposed authentication mechanisms.

Remediation focuses on eliminating SSL 3.0 and ensuring credentials are always protected by strong transport security. On the server or reverse proxy, disable SSL 3.0 and prefer TLS 1.2 or 1.3 with strong ciphersuites (e.g., AES-GCM). For Flask development, avoid using Werkzeug’s built-in server in production; use a production-ready WSGI server behind a properly configured TLS endpoint.

Additionally, prefer token-based authentication over sending passwords repeatedly via Basic Auth. When Basic Auth is necessary, ensure it is only used over strong TLS and never on legacy protocols. Below are concrete Flask examples that demonstrate insecure and secure patterns.

Insecure: Flask with Basic Auth served over SSL 3.0-capable endpoint

from flask import Flask, request, Response
import base64

app = Flask(__name__)

# WARNING: This example assumes an external TLS termination that might still allow SSL 3.0.
# Do not deploy this without enforcing modern TLS and disabling SSL 3.0.
@app.route('/api/protected')
def protected():
    auth = request.headers.get('Authorization', '')
    if auth.startswith('Basic '):
        encoded = auth.split(' ')[1]
        decoded = base64.b64decode(encoded).decode('utf-8')
        username, password = decoded.split(':', 1)
        # naive check — in real apps validate securely
        if username == 'admin' and password == 'secret':
            return 'OK'
    return Response('Unauthorized', 401, {'WWW-Authenticate': 'Basic'})

if __name__ == '__main__':
    # Development only; do not use in production without a strong TLS frontend
    app.run(debug=True, ssl_context='adhoc')

Secure: Enforce modern TLS and avoid SSL 3.0; consider replacing Basic Auth with token-based flows

from flask import Flask, request, jsonify

app = Flask(__name__)

# Use this pattern behind a reverse proxy that terminates TLS with modern protocols and ciphers.
# The proxy should explicitly disable SSL 3.0 and use strong ciphersuites.
@app.route('/api/protected')
def protected():
    auth = request.headers.get('Authorization', '')
    if auth.startswith('Basic '):
        encoded = auth.split(' ')[1]
        decoded = base64.b64decode(encoded).decode('utf-8')
        username, password = decoded.split(':', 1)
        # Validate credentials securely (e.g., constant-time compare, hashed storage)
        if username == 'admin' and password == 'strongPassword123':
            return jsonify({'status': 'authorized'})
    return jsonify({'error': 'Unauthorized'}), 401

# Example of migrating to token-based access (recommended):
# 1. Expose an OAuth2 or OpenID Connect endpoint for token issuance.
# 2. Require an Authorization: Bearer  header for protected routes.
# 3. Validate tokens using a library and verify scopes, audience, and issuer.
# 4. Enforce HTTPS at the infrastructure level (HSTS, modern ciphers, TLS 1.2+).

Infrastructure and operational steps

• Disable SSL 3.0 on load balancers, CDN, and web servers.
• Use strong ciphersuites and prefer TLS 1.2 or 1.3.
• Employ HTTP Strict Transport Security (HSTS) to prevent protocol downgrade.
• Consider replacing Basic Auth with OAuth2 client credentials or similar flows to avoid repeated password transmission.

middleBrick’s Continuous Monitoring (Pro plan) can track your API’s TLS configuration over time and alert you if SSL 3.0 is re-enabled. The GitHub Action can fail builds when scans detect weak protocols, and the MCP Server lets you validate API security directly from your IDE.