Host header poisoning
Several earlier Django security releases focused on the issue of
poisoning the HTTP Host header, causing Django to generate URLs
pointing to arbitrary, potentially-malicious domains.
In response to further input received and reports of continuing
issues following the previous release, we're taking additional
steps to tighten Host header validation. Rather than attempt to
accommodate all features HTTP supports here, Django's Host header
validation attempts to support a smaller, but far more common, subset:
- Hostnames must consist of characters [A-Za-z0-9] plus hyphen
('-') or dot ('.').
- IP addresses -- both IPv4 and IPv6 -- are permitted.
- Port, if specified, is numeric.
Any deviation from this will now be rejected, raising the exception
django.core.exceptions.SuspiciousOperation.
Redirect poisoning
Also following up on a previous issue: in July of this year, we made
changes to Django's HTTP redirect classes, performing additional
validation of the scheme of the URL to redirect to (since, both
within Django's own supplied applications and many third-party
applications, accepting a user-supplied redirect target is a common
pattern).
Since then, two independent audits of the code turned up further
potential problems. So, similar to the Host-header issue, we are
taking steps to provide tighter validation in response to reported
problems (primarily with third-party applications, but to a certain
extent also within Django itself). This comes in two parts:
- A new utility function, django.utils.http.is_safe_url, is
added; this function takes a URL and a hostname, and checks
that the URL is either relative, or if absolute matches the
supplied hostname. This function is intended for use whenever
user-supplied redirect targets are accepted, to ensure that
such redirects cannot lead to arbitrary third-party sites.
- All of Django's own built-in views -- primarily in the
authentication system -- which allow user-supplied redirect
targets now use is_safe_url to validate the supplied URL.