CVE-2017-7234

What it actually does

The vulnerability exists in the `django.views.static.serve()` view, which is intended for serving files during development. A maliciously crafted URL can abuse this view to cause an HTTP redirect to an arbitrary external domain. The server itself is not compromised, but its trusted domain is used to initiate a redirect to a potentially malicious location, lending it an unearned air of legitimacy.

Why it matters to the business

This open redirect vulnerability can be used to facilitate phishing campaigns against a company's users. Attackers can craft links that appear to originate from the trusted website but redirect users to malicious sites designed to steal credentials, distribute malware, or commit fraud. Successful exploitation erodes user trust, can lead to financial loss for customers, and causes significant reputational damage to the brand.

How an attack unfolds

An attacker first identifies a Django website improperly using the `django.views.static.serve()` view in a production environment. The attacker then crafts a special URL that targets this view but includes an external, attacker-controlled domain in the path. This malicious link is distributed to victims through phishing emails, social media, or other channels, masquerading as a legitimate link to the trusted site. When a victim clicks the link, their browser sends a request to the vulnerable Django server. The server processes the request and issues an HTTP 3xx redirect response, pointing the user's browser to the attacker's domain. The victim's browser automatically follows this redirect, landing them on the malicious site where they may be phished for credentials or served malware.

How to fix it

The primary remediation is to upgrade Django to a patched version: Django 1.10.7 or later, 1.9.13 or later, or 1.8.18 or later. As a fundamental best practice, you should not use `django.views.static.serve()` in a production environment. This view is inefficient and insecure for production use. Configure a dedicated web server such as Nginx or Apache to serve static files, or use a cloud storage service and CDN. Ensure your production `settings.py` has `DEBUG = False` and your `urls.py` does not route to `django.views.static.serve()`.

How to confirm the fix worked

To validate the fix, first confirm that the Django version in your environment is patched by running `python -m django --version` or checking your dependency management file. Second, audit your project's `urls.py` files to ensure that `django.views.static.serve` is not used in any URL patterns for the production environment. You can also perform a negative test by attempting to craft a URL with a double-slash prefix (e.g., `https://[your-site]/[static-path-prefix]//example.com`) and verifying that it does not redirect to `example.com`, but instead results in a 404 Not Found error.

Typical attack path

1. Attacker identifies a Django site using the vulnerable `django.views.static.serve` view in production.
2. Attacker crafts a malicious URL containing a protocol-relative path (e.g., `//malicious.com`) targeting the static view.
3. Attacker distributes the URL to victims via a phishing campaign.
4. Victim clicks the trusted-looking link.
5. The vulnerable Django application returns an HTTP 302 redirect to the attacker's malicious site.
6. Victim's browser is redirected to the malicious site, which can be used for phishing or malware delivery.

How to detect it

To detect potential exploitation, security teams should analyze web server access logs (e.g., from Nginx, Apache, or other reverse proxies) and application logs. Look for HTTP GET requests to URL paths associated with static file serving that result in a 301 or 302 redirect. The key indicator of an exploitation attempt is a request path that begins with a double forward slash (`//`) or double backslash (`\\`) immediately following the static directory prefix, which tricks the server into generating a redirect to an external, protocol-relative URL.

• GET /static//<external_domain>
• GET /media//<external_domain>

What your security team should do

• Immediately upgrade all affected Django applications to a patched version (1.10.7+, 1.9.13+, or 1.8.18+).
• Audit all Django projects to identify and remove any use of `django.views.static.serve` in production URL configurations, replacing it with a proper static file serving strategy.
• Scan web server access logs for request patterns indicative of exploitation attempts, such as requests to static paths containing `//` or `\\` followed by an external domain.