1. ==========================
    
  2. Django 1.4.3 release notes
    
  3. ==========================
    
  4. 
    
  5. *December 10, 2012*
    
  6. 
    
  7. Django 1.4.3 addresses two security issues present in previous Django releases
    
  8. in the 1.4 series.
    
  9. 
    
  10. Please be aware that this security release is slightly different from previous
    
  11. ones. Both issues addressed here have been dealt with in prior security updates
    
  12. to Django. In one case, we have received ongoing reports of problems, and in
    
  13. the other we've chosen to take further steps to tighten up Django's code in
    
  14. response to independent discovery of potential problems from multiple sources.
    
  15. 
    
  16. Host header poisoning
    
  17. =====================
    
  18. 
    
  19. Several earlier Django security releases focused on the issue of poisoning the
    
  20. HTTP Host header, causing Django to generate URLs pointing to arbitrary,
    
  21. potentially-malicious domains.
    
  22. 
    
  23. In response to further input received and reports of continuing issues
    
  24. following the previous release, we're taking additional steps to tighten Host
    
  25. header validation. Rather than attempt to accommodate all features HTTP
    
  26. supports here, Django's Host header validation attempts to support a smaller,
    
  27. but far more common, subset:
    
  28. 
    
  29. * Hostnames must consist of characters ``[A-Za-z0-9]`` plus hyphen ('-') or dot
    
  30.   ('.').
    
  31. * IP addresses -- both IPv4 and IPv6 -- are permitted.
    
  32. * Port, if specified, is numeric.
    
  33. 
    
  34. Any deviation from this will now be rejected, raising the exception
    
  35. :exc:`django.core.exceptions.SuspiciousOperation`.
    
  36. 
    
  37. Redirect poisoning
    
  38. ==================
    
  39. 
    
  40. Also following up on a previous issue: in July of this year, we made changes to
    
  41. Django's HTTP redirect classes, performing additional validation of the scheme
    
  42. of the URL to redirect to (since, both within Django's own supplied
    
  43. applications and many third-party applications, accepting a user-supplied
    
  44. redirect target is a common pattern).
    
  45. 
    
  46. Since then, two independent audits of the code turned up further potential
    
  47. problems. So, similar to the Host-header issue, we are taking steps to provide
    
  48. tighter validation in response to reported problems (primarily with third-party
    
  49. applications, but to a certain extent also within Django itself). This comes in
    
  50. two parts:
    
  51. 
    
  52. 1. A new utility function, ``django.utils.http.is_safe_url``, is added; this
    
  53. function takes a URL and a hostname, and checks that the URL is either
    
  54. relative, or if absolute matches the supplied hostname. This function is
    
  55. intended for use whenever user-supplied redirect targets are accepted, to
    
  56. ensure that such redirects cannot lead to arbitrary third-party sites.
    
  57. 
    
  58. 2. All of Django's own built-in views -- primarily in the authentication system
    
  59. -- which allow user-supplied redirect targets now use ``is_safe_url`` to
    
  60. validate the supplied URL.