CVE-2017-12794

What it actually does

A flaw in the Django technical 500 debug page template fails to properly escape HTML characters in user-provided data. This allows for a reflected Cross-Site Scripting (XSS) attack. An attacker can inject arbitrary JavaScript code into the debug page, which will execute in the browser of any user who views it, typically a developer or system administrator.

Why it matters to the business

This vulnerability primarily affects non-production environments where debug mode is enabled. If exploited, an attacker could steal session cookies from a developer or administrator viewing the error page, leading to account takeover. Compromise of a privileged account, even in a development environment, can lead to source code theft, introduction of further vulnerabilities, or lateral movement into other corporate systems.

How an attack unfolds

An attacker first identifies a Django application running with the `DEBUG = True` setting. They then craft a malicious request containing a JavaScript payload, specifically designed to trigger a 500 server error. When a developer or administrator investigates the error, the application renders the technical debug page. Due to the lack of HTML autoescaping, the attacker's payload is rendered as executable code, not text. The script runs in the developer's browser, allowing the attacker to perform actions on their behalf, such as exfiltrating session cookies to an attacker-controlled server to hijack their session.

How to fix it

The primary remediation is to upgrade Django to a patched version. For the 1.10.x branch, upgrade to version 1.10.8 or later. For the 1.11.x branch, upgrade to version 1.11.5 or later. As a critical security best practice and a complete mitigation for this specific vulnerability, ensure that all production and internet-facing applications are configured with `DEBUG = False` in their settings file.

How to confirm the fix worked

To confirm remediation, verify that the Django version has been upgraded by running `python -m django --version`. More importantly, audit the settings file (e.g., `settings.py`) of all deployed applications to ensure that the `DEBUG` variable is set to `False`. In a controlled, non-production test environment, you can attempt to validate the vulnerability by setting `DEBUG = True`, triggering a 500 error with a request containing an XSS payload (e.g., `?<script>alert(1)</script>`), and confirming that the script does not execute when viewing the debug page.

Typical attack path

1. Attacker discovers a public-facing Django application running with `DEBUG = True`.
2. Attacker crafts a request with a malicious script payload that is known to cause a server-side exception (500 error).
3. Attacker sends the malicious request to the application.
4. A developer or administrator reviews the server logs and accesses the technical 500 debug page to investigate the error.
5. The malicious script from the attacker's request executes in the developer's browser.
6. The script steals the developer's session cookie and sends it to an attacker-controlled server, enabling account takeover.

How to detect it

To detect potential exploitation attempts, review web server access logs and application logs for requests that resulted in a 500 HTTP status code. Examine the URI, headers, and POST body of these requests for common XSS payloads, such as strings containing `<script>`, `onerror=`, `onload=`, or `javascript:`. Correlating these patterns with 500 errors from a Django application is a key indicator. Monitor for subsequent anomalous activity from developer or administrator accounts, such as logins from unusual IP addresses, which could suggest a successful session hijacking attack.

• requests with HTTP 500 responses containing `<script` in the URI or body
• requests with HTTP 500 responses containing `onerror=` in the URI or body
• requests with HTTP 500 responses containing `onload=` in the URI or body
• requests with HTTP 500 responses containing `javascript:` in the URI or body

What your security team should do

• Immediately audit all web applications to identify any Django instances running in production with `DEBUG = True` and disable it.
• Upgrade all vulnerable Django applications to version 1.10.8+ or 1.11.5+.
• Implement automated checks in CI/CD pipelines to prevent code from being deployed to production with debug mode enabled.