CVE-2016-2512

What it actually does

The `utils.http.is_safe_url` function in affected Django versions improperly parses URLs containing basic authentication syntax (e.g., `user@host`). This allows an attacker to craft a URL that appears to belong to a trusted domain but actually redirects to an attacker-controlled domain. This bypass of the URL validation mechanism can lead to open redirect vulnerabilities and, in some cases, cross-site scripting (XSS) if the content from the malicious URL is rendered within the context of the original application.

Why it matters to the business

This vulnerability exposes users to phishing attacks, where they can be redirected to malicious websites designed to steal their credentials or other sensitive information, leading to account compromise. Successful exploitation can result in significant reputational damage, loss of user trust, and potential financial fraud. If the flaw is leveraged for cross-site scripting, attackers could take over user sessions, deface web pages, or access sensitive data stored in the user's browser, further escalating the impact.

How an attack unfolds

An attacker identifies a web application built with a vulnerable version of Django that uses the `is_safe_url` function to validate redirects, a common pattern after user login. The attacker crafts a special URL, such as `http://trusted-site.com\@attacker-site.com`, and embeds it into a link. The vulnerable function incorrectly identifies `trusted-site.com` as the host and approves the URL as safe. The attacker then distributes this link to a victim via a phishing email or a post on a forum. When the victim clicks the link, their browser correctly interprets `attacker-site.com` as the destination host and navigates there. The attacker's site can then present a fake login page to harvest the victim's credentials or execute malicious scripts in their browser.

How to fix it

To remediate this vulnerability, upgrade Django to a patched version. For applications using the 1.8.x branch, upgrade to version 1.8.10 or later. For applications using the 1.9.x branch, upgrade to version 1.9.3 or later. If you are using a downstream product like juju-core on Ubuntu 14.04 LTS, ensure it is updated to version 1.25.6-0ubuntu1.14.04.2 or newer.

How to confirm the fix worked

To validate the fix, first verify that the Django version installed in your environment is 1.8.10 or newer, or 1.9.3 or newer. You can also perform a manual test in a non-production environment by identifying a feature that uses a redirect parameter (e.g., a login page with a `?next=` parameter). Attempt to supply a URL with the malicious format, such as `?next=http://your-app.com\@example.com`. If the application redirects to `example.com`, it is vulnerable. A patched application should reject the redirect or strip the user info part, preventing the redirect to the external domain.

Typical attack path

1. An attacker identifies a vulnerable Django application that uses the `is_safe_url` function for validating user-supplied redirect URLs.
2. The attacker crafts a malicious URL using the `user@host` syntax (e.g., `http://legitimate.site\@malicious.site`) to bypass the validation check.
3. The attacker distributes the malicious link to victims through phishing campaigns or by posting it on public forums.
4. A victim clicks the link, believing it leads to the legitimate application.
5. The vulnerable application processes the URL, deems it safe, and issues a redirect.
6. The victim's browser is redirected to the attacker-controlled malicious site, which can then be used for phishing or executing cross-site scripting attacks.

How to detect it

To detect potential exploitation, security teams should review web server access logs (e.g., Nginx, Apache) and application logs. Search for HTTP GET requests where URL parameters (commonly `next`, `redirect`, `continue`, `redirect_uri`) contain a URL that includes the `@` character or its URL-encoded equivalent (`%40`). An alert should trigger if a request parameter contains a pattern like `http://<domain>@<external_domain>`. Correlating these requests with subsequent HTTP 301/302 redirect responses to an external domain would be a strong indicator of an exploitation attempt.

• /?next=http://*@*
• /?next=http%3A%2F%2F*%40*
• /?redirect=http://*@*
• /?redirect=http%3A%2F%2F*%40*
• /?continue=http://*@*
• /?continue=http%3A%2F%2F*%40*

What your security team should do

• Immediately identify all web applications using vulnerable versions of the Django framework (versions before 1.8.10 and 1.9.x before 1.9.3).
• Prioritize patching for public-facing applications, especially those that handle user authentication or process redirects.
• Upgrade all affected Django instances to a patched version, such as 1.8.10+ or 1.9.3+.
• Review web server logs for indicators of past exploitation attempts, focusing on URL parameters containing the `@` symbol.