FreshPorts - VuXML

The Django Project reports:

1. 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.

2. 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.

< 1.4.3

< 1.3.5

The Django Project reports:

1. Host header poisoning

   Some parts of Django -- independent of end-user-written applications -- make use of full URLs, including domain name, which are generated from the HTTP Host header. Some attacks against this are beyond Django's ability to control, and require the web server to be properly configured; Django's documentation has for some time contained notes advising users on such configuration.

   Django's own built-in parsing of the Host header is, however, still vulnerable, as was reported to us recently. The Host header parsing in Django 1.3 and Django 1.4 -- specifically, django.http.HttpRequest.get_host() -- was incorrectly handling username/password information in the header. Thus, for example, the following Host header would be accepted by Django when running on "validsite.com":

   Host: validsite.com:random@evilsite.com

   Using this, an attacker can cause parts of Django -- particularly the password-reset mechanism -- to generate and display arbitrary URLs to users.

   To remedy this, the parsing in HttpRequest.get_host() is being modified; Host headers which contain potentially dangerous content (such as username/password pairs) now raise the exception django.core.exceptions.SuspiciousOperation.

2. Documentation of HttpOnly cookie option

   As of Django 1.4, session cookies are always sent with the HttpOnly flag, which provides some additional protection from cross-site scripting attacks by denying client-side scripts access to the session cookie.

   Though not directly a security issue in Django, it has been reported that the Django 1.4 documentation incorrectly described this change, by claiming that this was now the default for all cookies set by the HttpResponse.set_cookie() method.

   The Django documentation has been updated to reflect that this only applies to the session cookie. Users of Django are encouraged to review their use of set_cookie() to ensure that the HttpOnly flag is being set or unset appropriately.

< 1.4.2

< 1.3.4