CVE-2012-3442

What it actually does

The vulnerability exists in Django's redirect classes, which fail to validate the scheme of user-supplied redirect targets. This allows an attacker to specify a `data:` URI as the redirect location. When a victim's browser is redirected to this `data:` URI, it executes the content within it, typically HTML and JavaScript, in the security context of the vulnerable site. This leads to a cross-site scripting (XSS) attack.

Why it matters to the business

Exploitation of this vulnerability can lead to the compromise of user accounts, allowing attackers to steal sensitive information, perform actions on behalf of the user, and conduct phishing attacks. This can result in significant reputational damage, loss of customer trust, and potential regulatory fines if personal data is breached. Since the affected versions are very old, systems still running them are likely unsupported and exposed to numerous other high-risk vulnerabilities.

How an attack unfolds

An attacker first identifies a vulnerable Django application that redirects users based on a URL parameter (e.g., a `next` parameter on a login page). The attacker then crafts a malicious link, embedding a `data:` URI containing a JavaScript payload into this parameter. This link is delivered to a victim, typically through a phishing email or a deceptive post on another website. When the victim clicks the link, their browser sends the request to the Django application. The application, without validating the URL scheme, issues an HTTP redirect response with the `Location` header set to the attacker's `data:` URI. The victim's browser then processes the `data:` URI, executing the embedded script. This script can then perform malicious actions, such as stealing the user's session cookies and sending them to an attacker-controlled server.

How to fix it

To remediate this vulnerability, upgrade your Django installation to a patched version. For applications running Django 1.3.x, upgrade to version 1.3.2 or later. For applications running Django 1.4.x, upgrade to version 1.4.1 or later. It is strongly recommended to upgrade to a modern, fully supported version of Django, as these legacy versions are no longer maintained and contain other security flaws.

How to confirm the fix worked

To confirm remediation, verify the installed Django version by running `python -m django --version` in your application's environment and ensure it is a patched version (e.g., 1.3.2+, 1.4.1+, or a modern release). To test for exposure, perform a source code review of all uses of `HttpResponseRedirect` and `HttpResponsePermanentRedirect`. Verify that any URL passed to these functions that originates from user input is validated to ensure it uses an allowed scheme (e.g., `http`, `https`). Dynamic Application Security Testing (DAST) tools can also be used to automatically test redirect parameters by injecting `data:` URI payloads.

Typical attack path

1. Attacker identifies a vulnerable Django application endpoint that uses user input to generate a redirect.
2. Attacker crafts a malicious URL containing a `data:` URI with a JavaScript payload in the redirect parameter.
3. Attacker uses social engineering to trick a victim into clicking the malicious URL.
4. The victim's browser sends the request to the vulnerable application.
5. The application responds with a 301 or 302 redirect, setting the `Location` header to the malicious `data:` URI.
6. The victim's browser executes the script in the `data:` URI, leading to session hijacking or other client-side attacks.

How to detect it

To detect potential exploitation attempts, search web server access logs, reverse proxy logs, or WAF logs for incoming requests where URL query parameters contain a `data:` URI. Look for patterns like `?next=data:text/html...` or `&redirect_uri=data:application/javascript...`. Successful exploitation would result in the server issuing a 301 or 302 redirect response where the `Location` header contains the `data:` URI. Analyzing HTTP response logs, if available, can confirm if the malicious redirect was served to a client.

• data:text/html
• data:application/javascript
• data:application/x-javascript

What your security team should do

• Immediately identify all applications using Django and upgrade any instances running versions prior to 1.3.2 or 1.4.1 to a modern, supported release.
• If an immediate upgrade is not possible, implement a web application firewall (WAF) rule to block requests where common redirect parameters (e.g., 'next', 'redirect', 'returnTo') contain the string 'data:'.
• Mandate security code reviews for all redirect functionality to ensure user-provided URLs are always validated against an allow-list of schemes before being used.