Poodle Attack in Django

The POODLE (Padding Oracle On Downgraded Legacy Encryption) attack exploits a flaw in SSL 3.0’s CBC mode cipher suites. An active man‑in‑the‑middle can force a TLS connection to downgrade to SSL 3.0 and then decrypt sensitive data such as session cookies, Authorization headers, or CSRF tokens. In a Django deployment the vulnerability appears when the front‑end web server (gunicorn, uWSGI, nginx, Apache, etc.) is configured to accept SSL 3.0 connections. Even if Django itself does not implement SSL, the framework relies on the underlying transport to protect cookies that are marked with the Secure flag. When SSL 3.0 is allowed, an attacker can strip that flag or capture the cookie in clear text after a successful downgrade.

Typical Django‑specific code paths that increase impact include:

• Views that set request.session without SESSION_COOKIE_SECURE = True – the session cookie is sent over the insecure channel.
• API endpoints that rely on django.middleware.csrf.CsrfViewMiddleware but have CSRF_COOKIE_SECURE = False, allowing the CSRF token to be intercepted.
• Custom authentication views that return sensitive data in JSON responses; if the response is sniffed after a POODLE downgrade, credentials or API keys may be exposed.

Because the attack works at the TLS layer, any Django view that transmits authentication material over HTTP (or over a TLS connection that can be forced to SSL 3.0) is potentially vulnerable.

Detecting POODLE in a Django‑powered API involves two checks: (1) whether the server still offers SSL 3.0, and (2) whether critical cookies lack the Secure flag. middleBrick performs the first check automatically as part of its Encryption scan. When you run a scan against an API URL, the tool attempts a TLS handshake with SSL 3.0 enabled; if the handshake succeeds, the finding is reported under the Encryption category with severity high and includes remediation guidance.

You can also verify the issue manually with OpenSSL:

openssl s_client -ssl3 -connect api.example.com:443 -servername api.example.com

If the command returns a handshake success and shows a cipher suite, SSL 3.0 is still accepted.

For the cookie flag, middleBrick inspects the HTTP response headers of the scanned endpoint. If it sees a Set-Cookie header for sessionid or csrftoken without the Secure attribute, it flags a missing‑secure‑cookie finding (also under Encryption). This helps you spot Django settings where SESSION_COOKIE_SECURE or CSRF_COOKIE_SECURE are inadvertently left false.

CLI example:

middlebrick scan https://api.myapp.com

The JSON output will contain an encryption block with a poodle_vulnerable flag set to true when SSL 3.0 is enabled.

Mitigating POODLE requires disabling SSL 3.0 at the transport layer and ensuring Django’s session and CSRF cookies are only sent over secure channels. The fixes involve both server‑side configuration and Django settings.

1. Disable SSL 3.0 in the web server or load balancer.

• nginx:

server {
    listen 443 ssl;
    ssl_protocols TLSv1.2 TLSv1.3;   # explicitly disables SSLv3, TLSv1, TLSv1.1
    ssl_prefer_server_ciphers on;
    # … other ssl directives …
}

• Apache:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

• gunicorn (when terminating TLS directly):

gunicorn --certfile=/path/to/cert.pem --keyfile=/path/to/key.pem \
    --ssl-version=tlsv1_2 myproject.wsgi:application

2. Enforce secure cookies in Django.

Edit settings.py (or environment‑specific config) to set:

# settings.py
SESSION_COOKIE_SECURE = True
CSRF_COOKIE_SECURE = True
# Optional: redirect all HTTP to HTTPS
SECURE_SSL_REDIRECT = True
# HSTS to enforce future HTTPS use
SECURE_HSTS_SECONDS = 31536000  # 1 year
SECURE_HSTS_INCLUDE_SUBDOMAINS = True
SECURE_HSTS_PRELOAD = True

These flags cause Django’s SessionMiddleware and CsrfViewMiddleware to set the Secure attribute on cookies, ensuring they are never transmitted over a non‑HTTPS channel.

3. Enable Django’s SecurityMiddleware.

Make sure 'django.middleware.security.SecurityMiddleware' is near the top of MIDDLEWARE:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    # …
]

The SecurityMiddleware adds headers like X-Content-Type-Options and X-Frame-Options, and it respects the SECURE_* settings above.

After applying these changes, rescan the API with middleBrick:

middlebrick scan https://api.myapp.com

The encryption finding should now show SSL 3.0 disabled and all critical cookies marked Secure. This eliminates the POODLE attack surface for your Django application.