Commit 72e0b033 authored by Tim Graham's avatar Tim Graham
Browse files

[1.6.x] Fixed is_safe_url() to handle leading whitespace. 

This is a security fix. Disclosure following shortly.
parent d7597b31

django/utils/http.py

+1 −0
Original line number Diff line number Diff line
@@ -256,6 +256,7 @@ def is_safe_url(url, host=None): 
    """

    if not url:

        return False

    url = url.strip()

    # Chrome treats \ completely as /

    url = url.replace('\\', '/')

    # Chrome considers any URL with more than two slashes to be absolute, but

docs/releases/1.4.18.txt

+14 −0
Original line number Diff line number Diff line
@@ -31,6 +31,20 @@ development server now does the same. Django's development server is not 
recommended for production use, but matching the behavior of common production

servers reduces the surface area for behavior changes during deployment.



Mitigated possible XSS attack via user-supplied redirect URLs

=============================================================



Django relies on user input in some cases (e.g.

:func:`django.contrib.auth.views.login` and :doc:`i18n </topics/i18n/index>`)

to redirect the user to an "on success" URL. The security checks for these

redirects (namely ``django.util.http.is_safe_url()``) didn't strip leading

whitespace on the tested URL and as such considered URLs like

``\njavascript:...`` safe. If a developer relied on ``is_safe_url()`` to

provide safe redirect targets and put such a URL into a link, they could suffer

from a XSS attack. This bug doesn't affect Django currently, since we only put

this URL into the ``Location`` response header and browsers seem to ignore

JavaScript there.



Bugfixes

========

docs/releases/1.6.10.txt

+14 −0
Original line number Diff line number Diff line
@@ -29,3 +29,17 @@ containing underscores from incoming requests by default. Django's built-in 
development server now does the same. Django's development server is not

recommended for production use, but matching the behavior of common production

servers reduces the surface area for behavior changes during deployment.



Mitigated possible XSS attack via user-supplied redirect URLs

=============================================================



Django relies on user input in some cases (e.g.

:func:`django.contrib.auth.views.login` and :doc:`i18n </topics/i18n/index>`)

to redirect the user to an "on success" URL. The security checks for these

redirects (namely ``django.util.http.is_safe_url()``) didn't strip leading

whitespace on the tested URL and as such considered URLs like

``\njavascript:...`` safe. If a developer relied on ``is_safe_url()`` to

provide safe redirect targets and put such a URL into a link, they could suffer

from a XSS attack. This bug doesn't affect Django currently, since we only put

this URL into the ``Location`` response header and browsers seem to ignore

JavaScript there.

tests/utils_tests/test_http.py

+2 −1
Original line number Diff line number Diff line
@@ -109,7 +109,8 @@ class TestUtilsHttp(unittest.TestCase): 
                        'http:/\//example.com',

                        'http:\/example.com',

                        'http:/\example.com',

                        'javascript:alert("XSS")'):

                        'javascript:alert("XSS")',

                        '\njavascript:alert(x)'):

            self.assertFalse(http.is_safe_url(bad_url, host='testserver'), "%s should be blocked" % bad_url)

        for good_url in ('/view/?param=http://example.com',

                     '/view/?param=https://example.com',