summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTim Graham <timograham@gmail.com>2015-03-09 20:05:13 -0400
committerTim Graham <timograham@gmail.com>2015-03-18 19:23:21 -0400
commit770427c2896a078925abfca2317486b284d22f04 (patch)
treeb60302538228595b1867d0e9ab6399969f650fe1
parent5447709a571cd5d95971f1d5d21d4a7edcf85bbd (diff)
[1.8.x] Made is_safe_url() reject URLs that start with control characters.
This is a security fix; disclosure to follow shortly.
-rw-r--r--django/utils/http.py9
-rw-r--r--docs/releases/1.4.20.txt19
-rw-r--r--docs/releases/1.6.11.txt19
-rw-r--r--docs/releases/1.7.7.txt19
-rw-r--r--tests/utils_tests/test_http.py4
5 files changed, 68 insertions, 2 deletions
diff --git a/django/utils/http.py b/django/utils/http.py
index 33515eb410..34c17424f6 100644
--- a/django/utils/http.py
+++ b/django/utils/http.py
@@ -5,6 +5,7 @@ import calendar
import datetime
import re
import sys
+import unicodedata
from binascii import Error as BinasciiError
from email.utils import formatdate
@@ -272,9 +273,10 @@ def is_safe_url(url, host=None):
Always returns ``False`` on an empty url.
"""
+ if url is not None:
+ url = url.strip()
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
@@ -288,5 +290,10 @@ def is_safe_url(url, host=None):
# allow this syntax.
if not url_info.netloc and url_info.scheme:
return False
+ # Forbid URLs that start with control characters. Some browsers (like
+ # Chrome) ignore quite a few control characters at the start of a
+ # URL and might consider the URL as scheme relative.
+ if unicodedata.category(url[0])[0] == 'C':
+ return False
return ((not url_info.netloc or url_info.netloc == host) and
(not url_info.scheme or url_info.scheme in ['http', 'https']))
diff --git a/docs/releases/1.4.20.txt b/docs/releases/1.4.20.txt
index 9c46c5510f..f2ca5ac103 100644
--- a/docs/releases/1.4.20.txt
+++ b/docs/releases/1.4.20.txt
@@ -5,3 +5,22 @@ Django 1.4.20 release notes
*March 18, 2015*
Django 1.4.20 fixes one security issue in 1.4.19.
+
+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.utils.http.is_safe_url()``) accepted URLs with
+leading control characters and so considered URLs like ``\x08javascript:...``
+safe. This issue doesn't affect Django currently, since we only put this URL
+into the ``Location`` response header and browsers seem to ignore JavaScript
+there. Browsers we tested also treat URLs prefixed with control characters such
+as ``%08//example.com`` as relative paths so redirection to an unsafe target
+isn't a problem either.
+
+However, if a developer relies on ``is_safe_url()`` to
+provide safe redirect targets and puts such a URL into a link, they could
+suffer from an XSS attack as some browsers such as Google Chrome ignore control
+characters at the start of a URL in an anchor ``href``.
diff --git a/docs/releases/1.6.11.txt b/docs/releases/1.6.11.txt
index a7d020c004..f1063fcff7 100644
--- a/docs/releases/1.6.11.txt
+++ b/docs/releases/1.6.11.txt
@@ -22,3 +22,22 @@ it detects the length of the string it's processing increases. Remember that
absolutely NO guarantee is provided about the results of ``strip_tags()`` being
HTML safe. So NEVER mark safe the result of a ``strip_tags()`` call without
escaping it first, for example with :func:`~django.utils.html.escape`.
+
+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.utils.http.is_safe_url()``) accepted URLs with
+leading control characters and so considered URLs like ``\x08javascript:...``
+safe. This issue doesn't affect Django currently, since we only put this URL
+into the ``Location`` response header and browsers seem to ignore JavaScript
+there. Browsers we tested also treat URLs prefixed with control characters such
+as ``%08//example.com`` as relative paths so redirection to an unsafe target
+isn't a problem either.
+
+However, if a developer relies on ``is_safe_url()`` to
+provide safe redirect targets and puts such a URL into a link, they could
+suffer from an XSS attack as some browsers such as Google Chrome ignore control
+characters at the start of a URL in an anchor ``href``.
diff --git a/docs/releases/1.7.7.txt b/docs/releases/1.7.7.txt
index 85c3154efd..c458368895 100644
--- a/docs/releases/1.7.7.txt
+++ b/docs/releases/1.7.7.txt
@@ -23,6 +23,25 @@ absolutely NO guarantee is provided about the results of ``strip_tags()`` being
HTML safe. So NEVER mark safe the result of a ``strip_tags()`` call without
escaping it first, for example with :func:`~django.utils.html.escape`.
+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.utils.http.is_safe_url()``) accepted URLs with
+leading control characters and so considered URLs like ``\x08javascript:...``
+safe. This issue doesn't affect Django currently, since we only put this URL
+into the ``Location`` response header and browsers seem to ignore JavaScript
+there. Browsers we tested also treat URLs prefixed with control characters such
+as ``%08//example.com`` as relative paths so redirection to an unsafe target
+isn't a problem either.
+
+However, if a developer relies on ``is_safe_url()`` to
+provide safe redirect targets and puts such a URL into a link, they could
+suffer from an XSS attack as some browsers such as Google Chrome ignore control
+characters at the start of a URL in an anchor ``href``.
+
Bugfixes
========
diff --git a/tests/utils_tests/test_http.py b/tests/utils_tests/test_http.py
index 7e48fe70a7..74c6905294 100644
--- a/tests/utils_tests/test_http.py
+++ b/tests/utils_tests/test_http.py
@@ -115,7 +115,9 @@ class TestUtilsHttp(unittest.TestCase):
'http:\/example.com',
'http:/\example.com',
'javascript:alert("XSS")',
- '\njavascript:alert(x)'):
+ '\njavascript:alert(x)',
+ '\x08//example.com',
+ '\n'):
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',