CVE-2015-0220

@@ -234,6 +234,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

@@ -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
 ========
 

@@ -64,7 +64,7 @@ def test_base36(self):
         # bad input
         for n in [-1, sys.maxint+1, '1', 'foo', {1:2}, (1,2,3)]:
             self.assertRaises(ValueError, http.int_to_base36, n)
-        
+
         for n in ['#', ' ']:
             self.assertRaises(ValueError, http.base36_to_int, n)
 
@@ -73,7 +73,7 @@ def test_base36(self):
 
         # non-integer input
         self.assertRaises(TypeError, http.int_to_base36, 3.141)
-        
+
         # more explicit output testing
         for n, b36 in [(0, '0'), (1, '1'), (42, '16'), (818469960, 'django')]:
             self.assertEqual(http.int_to_base36(n), b36)
@@ -97,7 +97,8 @@ def test_is_safe_url(self):
                         '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',

@@ -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

@@ -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
 ========
 

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

@@ -109,7 +109,8 @@ def test_is_safe_url(self):
                         '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',

@@ -272,6 +272,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

@@ -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
 ========
 

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

@@ -30,6 +30,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
 ========
 

@@ -107,7 +107,8 @@ def test_is_safe_url(self):
                         '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',