summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTim Graham <timograham@gmail.com>2014-12-03 16:14:00 -0500
committerTim Graham <timograham@gmail.com>2015-01-05 13:43:32 -0500
commit4c241f1b710da6419d9dca160e80b23b82db7758 (patch)
treee82fe8840c7dcdc7fabd6f0f7ae79835934a6d51
parent4f6fffc1dc429f1ad428ecf8e6620739e8837450 (diff)
[1.4.x] Fixed is_safe_url() to handle leading whitespace.
This is a security fix. Disclosure following shortly.
-rw-r--r--django/utils/http.py1
-rw-r--r--docs/releases/1.4.18.txt14
-rw-r--r--tests/regressiontests/utils/http.py7
3 files changed, 19 insertions, 3 deletions
diff --git a/django/utils/http.py b/django/utils/http.py
index 2d404890b5..e69a92b578 100644
--- a/django/utils/http.py
+++ b/django/utils/http.py
@@ -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
diff --git a/docs/releases/1.4.18.txt b/docs/releases/1.4.18.txt
index 55256cfdf3..2da42533bd 100644
--- a/docs/releases/1.4.18.txt
+++ b/docs/releases/1.4.18.txt
@@ -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
========
diff --git a/tests/regressiontests/utils/http.py b/tests/regressiontests/utils/http.py
index 802b3fa88d..3ec237ae64 100644
--- a/tests/regressiontests/utils/http.py
+++ b/tests/regressiontests/utils/http.py
@@ -64,7 +64,7 @@ class TestUtilsHttp(unittest.TestCase):
# 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 @@ class TestUtilsHttp(unittest.TestCase):
# 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 @@ 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',