123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960 |
- ==========================
- Django 1.3.5 release notes
- ==========================
- *December 10, 2012*
- Django 1.3.5 addresses two security issues present in previous Django releases
- in the 1.3 series.
- Please be aware that this security release is slightly different from previous
- ones. Both issues addressed here have been dealt with in prior security updates
- to Django. In one case, we have received ongoing reports of problems, and in
- the other we've chosen to take further steps to tighten up Django's code in
- response to independent discovery of potential problems from multiple sources.
- 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
- :exc:`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:
- 1. 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.
- 2. 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.
|