+31
-1
lines changedFilter options
+31
-1
lines changed Original file line number Diff line number Diff line change
@@ -256,6 +256,7 @@ def is_safe_url(url, host=None):
256 256
"""
257 257
if not url:
258 258
return False
259 +
url = url.strip()
259 260
# Chrome treats \ completely as /
260 261
url = url.replace('\\', '/')
261 262
# 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
31 31
recommended for production use, but matching the behavior of common production
32 32
servers reduces the surface area for behavior changes during deployment.
33 33 34 +
Mitigated possible XSS attack via user-supplied redirect URLs
35 +
=============================================================
36 + 37 +
Django relies on user input in some cases (e.g.
38 +
:func:`django.contrib.auth.views.login` and :doc:`i18n </topics/i18n/index>`)
39 +
to redirect the user to an "on success" URL. The security checks for these
40 +
redirects (namely ``django.util.http.is_safe_url()``) didn't strip leading
41 +
whitespace on the tested URL and as such considered URLs like
42 +
``\njavascript:...`` safe. If a developer relied on ``is_safe_url()`` to
43 +
provide safe redirect targets and put such a URL into a link, they could suffer
44 +
from a XSS attack. This bug doesn't affect Django currently, since we only put
45 +
this URL into the ``Location`` response header and browsers seem to ignore
46 +
JavaScript there.
47 + 34 48
Bugfixes
35 49
========
36 50
@@ -29,3 +29,17 @@ containing underscores from incoming requests by default. Django's built-in
29 29
development server now does the same. Django's development server is not
30 30
recommended for production use, but matching the behavior of common production
31 31
servers reduces the surface area for behavior changes during deployment.
32 + 33 +
Mitigated possible XSS attack via user-supplied redirect URLs
34 +
=============================================================
35 + 36 +
Django relies on user input in some cases (e.g.
37 +
:func:`django.contrib.auth.views.login` and :doc:`i18n </topics/i18n/index>`)
38 +
to redirect the user to an "on success" URL. The security checks for these
39 +
redirects (namely ``django.util.http.is_safe_url()``) didn't strip leading
40 +
whitespace on the tested URL and as such considered URLs like
41 +
``\njavascript:...`` safe. If a developer relied on ``is_safe_url()`` to
42 +
provide safe redirect targets and put such a URL into a link, they could suffer
43 +
from a XSS attack. This bug doesn't affect Django currently, since we only put
44 +
this URL into the ``Location`` response header and browsers seem to ignore
45 +
JavaScript there.
Original file line number Diff line number Diff line change
@@ -109,7 +109,8 @@ def test_is_safe_url(self):
109 109
'http:/\//example.com',
110 110
'http:\/example.com',
111 111
'http:/\example.com',
112 -
'javascript:alert("XSS")'):
112 +
'javascript:alert("XSS")',
113 +
'\njavascript:alert(x)'):
113 114
self.assertFalse(http.is_safe_url(bad_url, host='testserver'), "%s should be blocked" % bad_url)
114 115
for good_url in ('/view/?param=http://example.com',
115 116
'/view/?param=https://example.com',
You can’t perform that action at this time.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4