2008-12-02 22:40:00 +00:00
|
|
|
# -*- coding: utf-8 -*-
|
2012-06-07 16:08:47 +00:00
|
|
|
from __future__ import unicode_literals
|
2015-01-28 12:35:27 +00:00
|
|
|
|
2013-05-18 11:09:38 +00:00
|
|
|
import logging
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
import re
|
|
|
|
|
import warnings
|
2008-12-02 22:40:00 +00:00
|
|
|
|
2011-10-13 18:51:33 +00:00
|
|
|
from django.conf import settings
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
from django.http import HttpRequest, HttpResponse
|
2015-04-24 06:24:38 +00:00
|
|
|
from django.middleware.csrf import (
|
2016-06-03 00:24:48 +00:00
|
|
|
CSRF_TOKEN_LENGTH, REASON_BAD_TOKEN, REASON_NO_CSRF_COOKIE,
|
|
|
|
|
CsrfViewMiddleware, _compare_salted_tokens as equivalent_tokens, get_token,
|
2015-04-24 06:24:38 +00:00
|
|
|
)
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
from django.template import RequestContext, Template
|
2014-12-02 22:23:51 +00:00
|
|
|
from django.template.context_processors import csrf
|
2015-04-17 21:38:20 +00:00
|
|
|
from django.test import SimpleTestCase, override_settings
|
2016-06-03 00:24:48 +00:00
|
|
|
from django.test.utils import patch_logger
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
from django.utils.encoding import force_bytes
|
|
|
|
|
from django.utils.six import text_type
|
2015-01-28 12:35:27 +00:00
|
|
|
from django.views.decorators.csrf import (
|
|
|
|
|
csrf_exempt, ensure_csrf_cookie, requires_csrf_token,
|
|
|
|
|
)
|
2011-10-13 18:51:33 +00:00
|
|
|
|
2008-12-02 22:40:00 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
# Response/views used for CsrfResponseMiddleware and CsrfViewMiddleware tests
|
2008-12-03 00:34:18 +00:00
|
|
|
def post_form_response():
|
2012-06-07 16:08:47 +00:00
|
|
|
resp = HttpResponse(content="""
|
2010-09-10 22:56:56 +00:00
|
|
|
<html><body><h1>\u00a1Unicode!<form method="post"><input type="text" /></form></body></html>
|
2008-12-03 00:34:18 +00:00
|
|
|
""", mimetype="text/html")
|
|
|
|
|
return resp
|
|
|
|
|
|
2013-11-03 04:36:09 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def post_form_view(request):
|
|
|
|
|
"""A view that returns a POST form (without a token)"""
|
2008-12-03 00:34:18 +00:00
|
|
|
return post_form_response()
|
|
|
|
|
|
2013-11-03 04:36:09 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
# Response/views used for template tag tests
|
|
|
|
|
|
|
|
|
|
def token_view(request):
|
|
|
|
|
"""A view that uses {% csrf_token %}"""
|
2011-03-30 17:35:50 +00:00
|
|
|
context = RequestContext(request, processors=[csrf])
|
|
|
|
|
template = Template("{% csrf_token %}")
|
|
|
|
|
return HttpResponse(template.render(context))
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
|
2013-11-03 04:36:09 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def non_token_view_using_request_processor(request):
|
|
|
|
|
"""
|
|
|
|
|
A view that doesn't use the token, but does use the csrf view processor.
|
|
|
|
|
"""
|
|
|
|
|
context = RequestContext(request, processors=[csrf])
|
|
|
|
|
template = Template("")
|
|
|
|
|
return HttpResponse(template.render(context))
|
|
|
|
|
|
2013-11-03 04:36:09 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
class TestingHttpRequest(HttpRequest):
|
|
|
|
|
"""
|
|
|
|
|
A version of HttpRequest that allows us to change some things
|
|
|
|
|
more easily
|
|
|
|
|
"""
|
|
|
|
|
def is_secure(self):
|
2011-12-17 00:17:26 +00:00
|
|
|
return getattr(self, '_is_secure_override', False)
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
|
2013-11-03 04:36:09 +00:00
|
|
|
|
2015-04-17 21:38:20 +00:00
|
|
|
class CsrfViewMiddlewareTest(SimpleTestCase):
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
_csrf_id = _csrf_id_cookie = '1bcdefghij2bcdefghij3bcdefghij4bcdefghij5bcdefghij6bcdefghijABCD'
|
2008-12-02 22:40:00 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def _get_GET_no_csrf_cookie_request(self):
|
|
|
|
|
return TestingHttpRequest()
|
2008-12-02 22:40:00 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def _get_GET_csrf_cookie_request(self):
|
|
|
|
|
req = TestingHttpRequest()
|
2010-09-10 22:56:56 +00:00
|
|
|
req.COOKIES[settings.CSRF_COOKIE_NAME] = self._csrf_id_cookie
|
2008-12-02 22:40:00 +00:00
|
|
|
return req
|
|
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def _get_POST_csrf_cookie_request(self):
|
|
|
|
|
req = self._get_GET_csrf_cookie_request()
|
2008-12-02 23:00:06 +00:00
|
|
|
req.method = "POST"
|
|
|
|
|
return req
|
|
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def _get_POST_no_csrf_cookie_request(self):
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
2008-12-02 23:00:06 +00:00
|
|
|
req.method = "POST"
|
|
|
|
|
return req
|
|
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def _get_POST_request_with_token(self):
|
|
|
|
|
req = self._get_POST_csrf_cookie_request()
|
|
|
|
|
req.POST['csrfmiddlewaretoken'] = self._csrf_id
|
2008-12-02 23:00:06 +00:00
|
|
|
return req
|
|
|
|
|
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
def _get_POST_bare_secret_csrf_cookie_request(self):
|
|
|
|
|
req = self._get_POST_no_csrf_cookie_request()
|
|
|
|
|
req.COOKIES[settings.CSRF_COOKIE_NAME] = self._csrf_id_cookie[:32]
|
|
|
|
|
return req
|
|
|
|
|
|
|
|
|
|
def _get_POST_bare_secret_csrf_cookie_request_with_token(self):
|
|
|
|
|
req = self._get_POST_bare_secret_csrf_cookie_request()
|
|
|
|
|
req.POST['csrfmiddlewaretoken'] = self._csrf_id_cookie[:32]
|
|
|
|
|
return req
|
|
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def _check_token_present(self, response, csrf_id=None):
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
text = text_type(response.content, response.charset)
|
|
|
|
|
match = re.search("name='csrfmiddlewaretoken' value='(.*?)'", text)
|
|
|
|
|
csrf_token = csrf_id or self._csrf_id
|
|
|
|
|
self.assertTrue(
|
|
|
|
|
match and equivalent_tokens(csrf_token, match.group(1)),
|
|
|
|
|
"Could not find csrfmiddlewaretoken to match %s" % csrf_token
|
|
|
|
|
)
|
2008-12-03 00:31:31 +00:00
|
|
|
|
2013-05-18 11:09:38 +00:00
|
|
|
def test_process_view_token_too_long(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
If the token is longer than expected, it is ignored and a new token is
|
|
|
|
|
created.
|
2013-05-18 11:09:38 +00:00
|
|
|
"""
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
req.COOKIES[settings.CSRF_COOKIE_NAME] = 'x' * 100000
|
2013-05-18 11:09:38 +00:00
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
csrf_cookie = resp2.cookies.get(settings.CSRF_COOKIE_NAME, False)
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
self.assertEqual(len(csrf_cookie.value), CSRF_TOKEN_LENGTH)
|
|
|
|
|
|
|
|
|
|
def test_process_view_token_invalid_chars(self):
|
|
|
|
|
"""
|
|
|
|
|
If the token contains non-alphanumeric characters, it is ignored and a
|
|
|
|
|
new token is created.
|
|
|
|
|
"""
|
|
|
|
|
token = ('!@#' + self._csrf_id)[:CSRF_TOKEN_LENGTH]
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
req.COOKIES[settings.CSRF_COOKIE_NAME] = token
|
|
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
csrf_cookie = resp2.cookies.get(settings.CSRF_COOKIE_NAME, False)
|
|
|
|
|
self.assertEqual(len(csrf_cookie.value), CSRF_TOKEN_LENGTH)
|
|
|
|
|
self.assertNotEqual(csrf_cookie.value, token)
|
|
|
|
|
|
|
|
|
|
def test_process_view_token_invalid_bytes(self):
|
|
|
|
|
"""
|
|
|
|
|
If the token contains improperly encoded unicode, it is ignored and a
|
|
|
|
|
new token is created.
|
|
|
|
|
"""
|
|
|
|
|
token = (b"<1>\xc2\xa1" + force_bytes(self._csrf_id, 'ascii'))[:CSRF_TOKEN_LENGTH]
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
req.COOKIES[settings.CSRF_COOKIE_NAME] = token
|
|
|
|
|
# We expect a UnicodeWarning here, because we used broken utf-8 on purpose
|
|
|
|
|
with warnings.catch_warnings():
|
|
|
|
|
warnings.filterwarnings("ignore", category=UnicodeWarning)
|
|
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
csrf_cookie = resp2.cookies.get(settings.CSRF_COOKIE_NAME, False)
|
|
|
|
|
self.assertEqual(len(csrf_cookie.value), CSRF_TOKEN_LENGTH)
|
|
|
|
|
self.assertNotEqual(csrf_cookie.value, token)
|
2012-02-11 04:18:15 +00:00
|
|
|
|
2011-03-30 17:34:26 +00:00
|
|
|
def test_process_response_get_token_used(self):
|
2010-06-08 14:35:48 +00:00
|
|
|
"""
|
2011-03-30 17:34:26 +00:00
|
|
|
When get_token is used, check that the cookie is created and headers
|
|
|
|
|
patched.
|
2010-06-08 14:35:48 +00:00
|
|
|
"""
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
|
2011-05-09 23:00:22 +00:00
|
|
|
# Put tests for CSRF_COOKIE_* settings here
|
|
|
|
|
with self.settings(CSRF_COOKIE_NAME='myname',
|
|
|
|
|
CSRF_COOKIE_DOMAIN='.example.com',
|
|
|
|
|
CSRF_COOKIE_PATH='/test/',
|
2013-02-07 08:48:08 +00:00
|
|
|
CSRF_COOKIE_SECURE=True,
|
|
|
|
|
CSRF_COOKIE_HTTPONLY=True):
|
2011-05-09 23:00:22 +00:00
|
|
|
# token_view calls get_token() indirectly
|
|
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
csrf_cookie = resp2.cookies.get('myname', False)
|
2016-06-16 18:19:18 +00:00
|
|
|
self.assertIsNot(csrf_cookie, False)
|
2011-05-09 23:00:22 +00:00
|
|
|
self.assertEqual(csrf_cookie['domain'], '.example.com')
|
2016-06-16 18:19:18 +00:00
|
|
|
self.assertIs(csrf_cookie['secure'], True)
|
|
|
|
|
self.assertIs(csrf_cookie['httponly'], True)
|
2011-05-09 23:00:22 +00:00
|
|
|
self.assertEqual(csrf_cookie['path'], '/test/')
|
2014-10-28 10:02:56 +00:00
|
|
|
self.assertIn('Cookie', resp2.get('Vary', ''))
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
|
|
|
|
|
def test_process_response_get_token_not_used(self):
|
2008-12-02 22:40:00 +00:00
|
|
|
"""
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
Check that if get_token() is not called, the view middleware does not
|
|
|
|
|
add a cookie.
|
2008-12-02 22:40:00 +00:00
|
|
|
"""
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
# This is important to make pages cacheable. Pages which do call
|
|
|
|
|
# get_token(), assuming they use the token, are not cacheable because
|
|
|
|
|
# the token is specific to the user
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
# non_token_view_using_request_processor does not call get_token(), but
|
|
|
|
|
# does use the csrf request processor. By using this, we are testing
|
|
|
|
|
# that the view processor is properly lazy and doesn't call get_token()
|
|
|
|
|
# until needed.
|
|
|
|
|
CsrfViewMiddleware().process_view(req, non_token_view_using_request_processor, (), {})
|
|
|
|
|
resp = non_token_view_using_request_processor(req)
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
|
|
|
|
|
csrf_cookie = resp2.cookies.get(settings.CSRF_COOKIE_NAME, False)
|
2016-06-16 18:19:18 +00:00
|
|
|
self.assertIs(csrf_cookie, False)
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
|
2008-12-02 23:00:06 +00:00
|
|
|
# Check the request processing
|
2011-03-30 17:34:14 +00:00
|
|
|
def test_process_request_no_csrf_cookie(self):
|
2008-12-02 23:00:06 +00:00
|
|
|
"""
|
2011-03-30 17:34:14 +00:00
|
|
|
Check that if no CSRF cookies is present, the middleware rejects the
|
|
|
|
|
incoming request. This will stop login CSRF.
|
2008-12-02 23:00:06 +00:00
|
|
|
"""
|
2016-06-03 00:24:48 +00:00
|
|
|
with patch_logger('django.security.csrf', 'warning') as logger_calls:
|
|
|
|
|
req = self._get_POST_no_csrf_cookie_request()
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertEqual(403, req2.status_code)
|
|
|
|
|
self.assertEqual(logger_calls[0], 'Forbidden (%s): ' % REASON_NO_CSRF_COOKIE)
|
2008-12-02 23:00:06 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def test_process_request_csrf_cookie_no_token(self):
|
2008-12-02 23:00:06 +00:00
|
|
|
"""
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
Check that if a CSRF cookie is present but no token, the middleware
|
|
|
|
|
rejects the incoming request.
|
2008-12-02 23:00:06 +00:00
|
|
|
"""
|
2016-06-03 00:24:48 +00:00
|
|
|
with patch_logger('django.security.csrf', 'warning') as logger_calls:
|
|
|
|
|
req = self._get_POST_csrf_cookie_request()
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertEqual(403, req2.status_code)
|
|
|
|
|
self.assertEqual(logger_calls[0], 'Forbidden (%s): ' % REASON_BAD_TOKEN)
|
2008-12-02 23:00:06 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def test_process_request_csrf_cookie_and_token(self):
|
2008-12-02 23:00:06 +00:00
|
|
|
"""
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
Check that if both a cookie and a token is present, the middleware lets it through.
|
2008-12-02 23:00:06 +00:00
|
|
|
"""
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
req = self._get_POST_request_with_token()
|
2011-03-30 17:34:26 +00:00
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
2015-01-06 07:48:01 +00:00
|
|
|
self.assertIsNone(req2)
|
2008-12-03 00:34:18 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def test_process_request_csrf_cookie_no_token_exempt_view(self):
|
|
|
|
|
"""
|
|
|
|
|
Check that if a CSRF cookie is present and no token, but the csrf_exempt
|
2008-12-03 00:34:18 +00:00
|
|
|
decorator has been applied to the view, the middleware lets it through
|
|
|
|
|
"""
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
req = self._get_POST_csrf_cookie_request()
|
2011-03-30 17:34:26 +00:00
|
|
|
req2 = CsrfViewMiddleware().process_view(req, csrf_exempt(post_form_view), (), {})
|
2015-01-06 07:48:01 +00:00
|
|
|
self.assertIsNone(req2)
|
2008-12-03 00:34:18 +00:00
|
|
|
|
2011-02-09 02:06:27 +00:00
|
|
|
def test_csrf_token_in_header(self):
|
2008-12-03 00:34:18 +00:00
|
|
|
"""
|
2011-02-09 02:06:27 +00:00
|
|
|
Check that we can pass in the token in a header instead of in the form
|
2008-12-03 00:34:18 +00:00
|
|
|
"""
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
req = self._get_POST_csrf_cookie_request()
|
2011-02-09 02:06:27 +00:00
|
|
|
req.META['HTTP_X_CSRFTOKEN'] = self._csrf_id
|
2011-03-30 17:34:26 +00:00
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
2015-02-21 21:57:02 +00:00
|
|
|
self.assertIsNone(req2)
|
|
|
|
|
|
|
|
|
|
@override_settings(CSRF_HEADER_NAME='HTTP_X_CSRFTOKEN_CUSTOMIZED')
|
|
|
|
|
def test_csrf_token_in_header_with_customized_name(self):
|
|
|
|
|
"""
|
|
|
|
|
settings.CSRF_HEADER_NAME can be used to customize the CSRF header name
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_csrf_cookie_request()
|
|
|
|
|
req.META['HTTP_X_CSRFTOKEN_CUSTOMIZED'] = self._csrf_id
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
2015-01-06 07:48:01 +00:00
|
|
|
self.assertIsNone(req2)
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
|
2011-05-09 23:45:54 +00:00
|
|
|
def test_put_and_delete_rejected(self):
|
|
|
|
|
"""
|
|
|
|
|
Tests that HTTP PUT and DELETE methods have protection
|
|
|
|
|
"""
|
|
|
|
|
req = TestingHttpRequest()
|
|
|
|
|
req.method = 'PUT'
|
2016-06-03 00:24:48 +00:00
|
|
|
with patch_logger('django.security.csrf', 'warning') as logger_calls:
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertEqual(403, req2.status_code)
|
|
|
|
|
self.assertEqual(logger_calls[0], 'Forbidden (%s): ' % REASON_NO_CSRF_COOKIE)
|
2011-05-09 23:45:54 +00:00
|
|
|
|
|
|
|
|
req = TestingHttpRequest()
|
|
|
|
|
req.method = 'DELETE'
|
2016-06-03 00:24:48 +00:00
|
|
|
with patch_logger('django.security.csrf', 'warning') as logger_calls:
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertEqual(403, req2.status_code)
|
|
|
|
|
self.assertEqual(logger_calls[0], 'Forbidden (%s): ' % REASON_NO_CSRF_COOKIE)
|
2011-05-09 23:45:54 +00:00
|
|
|
|
|
|
|
|
def test_put_and_delete_allowed(self):
|
|
|
|
|
"""
|
|
|
|
|
Tests that HTTP PUT and DELETE methods can get through with
|
|
|
|
|
X-CSRFToken and a cookie
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_GET_csrf_cookie_request()
|
|
|
|
|
req.method = 'PUT'
|
|
|
|
|
req.META['HTTP_X_CSRFTOKEN'] = self._csrf_id
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
2015-01-06 07:48:01 +00:00
|
|
|
self.assertIsNone(req2)
|
2011-05-09 23:45:54 +00:00
|
|
|
|
|
|
|
|
req = self._get_GET_csrf_cookie_request()
|
|
|
|
|
req.method = 'DELETE'
|
|
|
|
|
req.META['HTTP_X_CSRFTOKEN'] = self._csrf_id
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
2015-01-06 07:48:01 +00:00
|
|
|
self.assertIsNone(req2)
|
2011-05-09 23:45:54 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
# Tests for the template tag method
|
|
|
|
|
def test_token_node_no_csrf_cookie(self):
|
|
|
|
|
"""
|
|
|
|
|
Check that CsrfTokenNode works when no CSRF cookie is set
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
resp = token_view(req)
|
2015-04-24 06:24:38 +00:00
|
|
|
|
|
|
|
|
token = get_token(req)
|
|
|
|
|
self.assertIsNotNone(token)
|
|
|
|
|
self._check_token_present(resp, token)
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
|
2010-09-10 22:56:56 +00:00
|
|
|
def test_token_node_empty_csrf_cookie(self):
|
|
|
|
|
"""
|
|
|
|
|
Check that we get a new token if the csrf_cookie is the empty string
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
2012-06-07 16:08:47 +00:00
|
|
|
req.COOKIES[settings.CSRF_COOKIE_NAME] = b""
|
2010-09-10 22:56:56 +00:00
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
|
2015-04-24 06:24:38 +00:00
|
|
|
token = get_token(req)
|
|
|
|
|
self.assertIsNotNone(token)
|
|
|
|
|
self._check_token_present(resp, token)
|
2010-09-10 22:56:56 +00:00
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def test_token_node_with_csrf_cookie(self):
|
|
|
|
|
"""
|
|
|
|
|
Check that CsrfTokenNode works when a CSRF cookie is set
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_GET_csrf_cookie_request()
|
|
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
self._check_token_present(resp)
|
|
|
|
|
|
2010-06-08 14:35:48 +00:00
|
|
|
def test_get_token_for_exempt_view(self):
|
|
|
|
|
"""
|
2011-03-30 17:35:41 +00:00
|
|
|
Check that get_token still works for a view decorated with 'csrf_exempt'.
|
2010-06-08 14:35:48 +00:00
|
|
|
"""
|
|
|
|
|
req = self._get_GET_csrf_cookie_request()
|
2011-03-30 17:35:41 +00:00
|
|
|
CsrfViewMiddleware().process_view(req, csrf_exempt(token_view), (), {})
|
2010-06-08 14:35:48 +00:00
|
|
|
resp = token_view(req)
|
|
|
|
|
self._check_token_present(resp)
|
|
|
|
|
|
2010-10-28 11:47:15 +00:00
|
|
|
def test_get_token_for_requires_csrf_token_view(self):
|
|
|
|
|
"""
|
|
|
|
|
Check that get_token works for a view decorated solely with requires_csrf_token
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_GET_csrf_cookie_request()
|
|
|
|
|
resp = requires_csrf_token(token_view)(req)
|
|
|
|
|
self._check_token_present(resp)
|
|
|
|
|
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def test_token_node_with_new_csrf_cookie(self):
|
|
|
|
|
"""
|
|
|
|
|
Check that CsrfTokenNode works when a CSRF cookie is created by
|
|
|
|
|
the middleware (when one was not already present)
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
csrf_cookie = resp2.cookies[settings.CSRF_COOKIE_NAME]
|
|
|
|
|
self._check_token_present(resp, csrf_id=csrf_cookie.value)
|
|
|
|
|
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
def test_cookie_not_reset_on_accepted_request(self):
|
|
|
|
|
"""
|
|
|
|
|
The csrf token used in posts is changed on every request (although
|
|
|
|
|
stays equivalent). The csrf cookie should not change on accepted
|
|
|
|
|
requests. If it appears in the response, it should keep its value.
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
|
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
resp = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
csrf_cookie = resp.cookies.get(settings.CSRF_COOKIE_NAME, None)
|
|
|
|
|
if csrf_cookie:
|
|
|
|
|
self.assertEqual(
|
|
|
|
|
csrf_cookie.value, self._csrf_id_cookie,
|
|
|
|
|
"CSRF cookie was changed on an accepted request"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
def test_bare_secret_accepted_and_replaced(self):
|
|
|
|
|
"""
|
|
|
|
|
The csrf token is reset from a bare secret.
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_bare_secret_csrf_cookie_request_with_token()
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
self.assertIsNone(req2)
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
resp = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
self.assertIn(settings.CSRF_COOKIE_NAME, resp.cookies, "Cookie was not reset from bare secret")
|
|
|
|
|
csrf_cookie = resp.cookies[settings.CSRF_COOKIE_NAME]
|
|
|
|
|
self.assertEqual(len(csrf_cookie.value), CSRF_TOKEN_LENGTH)
|
|
|
|
|
self._check_token_present(resp, csrf_id=csrf_cookie.value)
|
|
|
|
|
|
2016-10-17 16:14:49 +00:00
|
|
|
@override_settings(DEBUG=True, ALLOWED_HOSTS=['www.example.com'])
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def test_https_bad_referer(self):
|
|
|
|
|
"""
|
|
|
|
|
Test that a POST HTTPS request with a bad referer is rejected
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
2011-12-17 00:17:26 +00:00
|
|
|
req._is_secure_override = True
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
req.META['HTTP_HOST'] = 'www.example.com'
|
|
|
|
|
req.META['HTTP_REFERER'] = 'https://www.evil.org/somepage'
|
2015-03-17 09:52:55 +00:00
|
|
|
req.META['SERVER_PORT'] = '443'
|
|
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertContains(
|
|
|
|
|
response,
|
|
|
|
|
'Referer checking failed - https://www.evil.org/somepage does not '
|
|
|
|
|
'match any trusted origins.',
|
|
|
|
|
status_code=403,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
@override_settings(DEBUG=True)
|
2013-05-18 10:32:47 +00:00
|
|
|
def test_https_malformed_referer(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
A POST HTTPS request with a bad referer is rejected.
|
2013-05-18 10:32:47 +00:00
|
|
|
"""
|
2015-03-17 09:52:55 +00:00
|
|
|
malformed_referer_msg = 'Referer checking failed - Referer is malformed.'
|
2013-05-18 10:32:47 +00:00
|
|
|
req = self._get_POST_request_with_token()
|
|
|
|
|
req._is_secure_override = True
|
|
|
|
|
req.META['HTTP_REFERER'] = 'http://http://www.example.com/'
|
2015-03-17 09:52:55 +00:00
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertContains(
|
|
|
|
|
response,
|
|
|
|
|
'Referer checking failed - Referer is insecure while host is secure.',
|
|
|
|
|
status_code=403,
|
|
|
|
|
)
|
|
|
|
|
# Empty
|
|
|
|
|
req.META['HTTP_REFERER'] = ''
|
|
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertContains(response, malformed_referer_msg, status_code=403)
|
2015-01-05 17:23:57 +00:00
|
|
|
# Non-ASCII
|
|
|
|
|
req.META['HTTP_REFERER'] = b'\xd8B\xf6I\xdf'
|
2015-03-17 09:52:55 +00:00
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertContains(response, malformed_referer_msg, status_code=403)
|
|
|
|
|
# missing scheme
|
|
|
|
|
# >>> urlparse('//example.com/')
|
|
|
|
|
# ParseResult(scheme='', netloc='example.com', path='/', params='', query='', fragment='')
|
|
|
|
|
req.META['HTTP_REFERER'] = '//example.com/'
|
|
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertContains(response, malformed_referer_msg, status_code=403)
|
|
|
|
|
# missing netloc
|
|
|
|
|
# >>> urlparse('https://')
|
|
|
|
|
# ParseResult(scheme='https', netloc='', path='', params='', query='', fragment='')
|
|
|
|
|
req.META['HTTP_REFERER'] = 'https://'
|
|
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertContains(response, malformed_referer_msg, status_code=403)
|
2013-05-18 10:32:47 +00:00
|
|
|
|
2013-02-09 17:17:01 +00:00
|
|
|
@override_settings(ALLOWED_HOSTS=['www.example.com'])
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
def test_https_good_referer(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
A POST HTTPS request with a good referer is accepted.
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
2011-12-17 00:17:26 +00:00
|
|
|
req._is_secure_override = True
|
Fixed #9977 - CsrfMiddleware gets template tag added, session dependency removed, and turned on by default.
This is a large change to CSRF protection for Django. It includes:
* removing the dependency on the session framework.
* deprecating CsrfResponseMiddleware, and replacing with a core template tag.
* turning on CSRF protection by default by adding CsrfViewMiddleware to
the default value of MIDDLEWARE_CLASSES.
* protecting all contrib apps (whatever is in settings.py)
using a decorator.
For existing users of the CSRF functionality, it should be a seamless update,
but please note that it includes DEPRECATION of features in Django 1.1,
and there are upgrade steps which are detailed in the docs.
Many thanks to 'Glenn' and 'bthomas', who did a lot of the thinking and work
on the patch, and to lots of other people including Simon Willison and
Russell Keith-Magee who refined the ideas.
Details of the rationale for these changes is found here:
http://code.djangoproject.com/wiki/CsrfProtection
As of this commit, the CSRF code is mainly in 'contrib'. The code will be
moved to core in a separate commit, to make the changeset as readable as
possible.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@11660 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-10-26 23:23:07 +00:00
|
|
|
req.META['HTTP_HOST'] = 'www.example.com'
|
|
|
|
|
req.META['HTTP_REFERER'] = 'https://www.example.com/somepage'
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
2015-01-06 07:48:01 +00:00
|
|
|
self.assertIsNone(req2)
|
2011-03-15 20:37:09 +00:00
|
|
|
|
2013-02-09 17:17:01 +00:00
|
|
|
@override_settings(ALLOWED_HOSTS=['www.example.com'])
|
2011-03-15 20:37:09 +00:00
|
|
|
def test_https_good_referer_2(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
A POST HTTPS request with a good referer is accepted where the referer
|
|
|
|
|
contains no trailing slash.
|
2011-03-15 20:37:09 +00:00
|
|
|
"""
|
|
|
|
|
# See ticket #15617
|
|
|
|
|
req = self._get_POST_request_with_token()
|
2011-12-17 00:17:26 +00:00
|
|
|
req._is_secure_override = True
|
2011-03-15 20:37:09 +00:00
|
|
|
req.META['HTTP_HOST'] = 'www.example.com'
|
|
|
|
|
req.META['HTTP_REFERER'] = 'https://www.example.com'
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
2015-01-06 07:48:01 +00:00
|
|
|
self.assertIsNone(req2)
|
2011-05-09 21:35:24 +00:00
|
|
|
|
2016-01-18 14:04:41 +00:00
|
|
|
@override_settings(ALLOWED_HOSTS=['www.example.com'], CSRF_COOKIE_DOMAIN='.example.com', USE_X_FORWARDED_PORT=True)
|
|
|
|
|
def test_https_good_referer_behind_proxy(self):
|
|
|
|
|
"""
|
|
|
|
|
A POST HTTPS request is accepted when USE_X_FORWARDED_PORT=True.
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
|
|
|
|
req._is_secure_override = True
|
|
|
|
|
req.META.update({
|
|
|
|
|
'HTTP_HOST': '10.0.0.2',
|
|
|
|
|
'HTTP_REFERER': 'https://www.example.com/somepage',
|
|
|
|
|
'SERVER_PORT': '8080',
|
|
|
|
|
'HTTP_X_FORWARDED_HOST': 'www.example.com',
|
|
|
|
|
'HTTP_X_FORWARDED_PORT': '443',
|
|
|
|
|
})
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertIsNone(req2)
|
|
|
|
|
|
2015-09-01 02:32:03 +00:00
|
|
|
@override_settings(ALLOWED_HOSTS=['www.example.com'], CSRF_TRUSTED_ORIGINS=['dashboard.example.com'])
|
|
|
|
|
def test_https_csrf_trusted_origin_allowed(self):
|
|
|
|
|
"""
|
|
|
|
|
A POST HTTPS request with a referer added to the CSRF_TRUSTED_ORIGINS
|
|
|
|
|
setting is accepted.
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
|
|
|
|
req._is_secure_override = True
|
|
|
|
|
req.META['HTTP_HOST'] = 'www.example.com'
|
|
|
|
|
req.META['HTTP_REFERER'] = 'https://dashboard.example.com'
|
|
|
|
|
req2 = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertIsNone(req2)
|
|
|
|
|
|
2015-03-17 09:52:55 +00:00
|
|
|
@override_settings(ALLOWED_HOSTS=['www.example.com'], CSRF_TRUSTED_ORIGINS=['.example.com'])
|
|
|
|
|
def test_https_csrf_wildcard_trusted_origin_allowed(self):
|
|
|
|
|
"""
|
|
|
|
|
A POST HTTPS request with a referer that matches a CSRF_TRUSTED_ORIGINS
|
2015-12-02 23:55:50 +00:00
|
|
|
wildcard is accepted.
|
2015-03-17 09:52:55 +00:00
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
|
|
|
|
req._is_secure_override = True
|
|
|
|
|
req.META['HTTP_HOST'] = 'www.example.com'
|
|
|
|
|
req.META['HTTP_REFERER'] = 'https://dashboard.example.com'
|
|
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertIsNone(response)
|
|
|
|
|
|
|
|
|
|
@override_settings(ALLOWED_HOSTS=['www.example.com'], CSRF_COOKIE_DOMAIN='.example.com')
|
|
|
|
|
def test_https_good_referer_matches_cookie_domain(self):
|
|
|
|
|
"""
|
|
|
|
|
A POST HTTPS request with a good referer should be accepted from a
|
|
|
|
|
subdomain that's allowed by CSRF_COOKIE_DOMAIN.
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
|
|
|
|
req._is_secure_override = True
|
|
|
|
|
req.META['HTTP_REFERER'] = 'https://foo.example.com/'
|
|
|
|
|
req.META['SERVER_PORT'] = '443'
|
|
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertIsNone(response)
|
|
|
|
|
|
|
|
|
|
@override_settings(ALLOWED_HOSTS=['www.example.com'], CSRF_COOKIE_DOMAIN='.example.com')
|
|
|
|
|
def test_https_good_referer_matches_cookie_domain_with_different_port(self):
|
|
|
|
|
"""
|
|
|
|
|
A POST HTTPS request with a good referer should be accepted from a
|
|
|
|
|
subdomain that's allowed by CSRF_COOKIE_DOMAIN and a non-443 port.
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
|
|
|
|
req._is_secure_override = True
|
|
|
|
|
req.META['HTTP_HOST'] = 'www.example.com'
|
|
|
|
|
req.META['HTTP_REFERER'] = 'https://foo.example.com:4443/'
|
|
|
|
|
req.META['SERVER_PORT'] = '4443'
|
|
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertIsNone(response)
|
|
|
|
|
|
|
|
|
|
@override_settings(CSRF_COOKIE_DOMAIN='.example.com', DEBUG=True)
|
|
|
|
|
def test_https_reject_insecure_referer(self):
|
|
|
|
|
"""
|
|
|
|
|
A POST HTTPS request from an insecure referer should be rejected.
|
|
|
|
|
"""
|
|
|
|
|
req = self._get_POST_request_with_token()
|
|
|
|
|
req._is_secure_override = True
|
|
|
|
|
req.META['HTTP_REFERER'] = 'http://example.com/'
|
|
|
|
|
req.META['SERVER_PORT'] = '443'
|
|
|
|
|
response = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertContains(
|
|
|
|
|
response,
|
|
|
|
|
'Referer checking failed - Referer is insecure while host is secure.',
|
|
|
|
|
status_code=403,
|
|
|
|
|
)
|
|
|
|
|
|
2011-05-09 21:35:24 +00:00
|
|
|
def test_ensures_csrf_cookie_no_middleware(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
The ensure_csrf_cookie() decorator works without middleware.
|
2011-05-09 21:35:24 +00:00
|
|
|
"""
|
|
|
|
|
@ensure_csrf_cookie
|
|
|
|
|
def view(request):
|
|
|
|
|
# Doesn't insert a token or anything
|
|
|
|
|
return HttpResponse(content="")
|
|
|
|
|
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
resp = view(req)
|
|
|
|
|
self.assertTrue(resp.cookies.get(settings.CSRF_COOKIE_NAME, False))
|
2014-10-28 10:02:56 +00:00
|
|
|
self.assertIn('Cookie', resp.get('Vary', ''))
|
2011-05-09 21:35:24 +00:00
|
|
|
|
|
|
|
|
def test_ensures_csrf_cookie_with_middleware(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
The ensure_csrf_cookie() decorator works with the CsrfViewMiddleware
|
|
|
|
|
enabled.
|
2011-05-09 21:35:24 +00:00
|
|
|
"""
|
|
|
|
|
@ensure_csrf_cookie
|
|
|
|
|
def view(request):
|
|
|
|
|
# Doesn't insert a token or anything
|
|
|
|
|
return HttpResponse(content="")
|
|
|
|
|
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
CsrfViewMiddleware().process_view(req, view, (), {})
|
|
|
|
|
resp = view(req)
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
self.assertTrue(resp2.cookies.get(settings.CSRF_COOKIE_NAME, False))
|
2014-10-28 10:02:56 +00:00
|
|
|
self.assertIn('Cookie', resp2.get('Vary', ''))
|
2013-05-18 11:09:38 +00:00
|
|
|
|
|
|
|
|
def test_ensures_csrf_cookie_no_logging(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
ensure_csrf_cookie() doesn't log warnings (#19436).
|
2013-05-18 11:09:38 +00:00
|
|
|
"""
|
|
|
|
|
@ensure_csrf_cookie
|
|
|
|
|
def view(request):
|
|
|
|
|
# Doesn't insert a token or anything
|
|
|
|
|
return HttpResponse(content="")
|
|
|
|
|
|
|
|
|
|
class TestHandler(logging.Handler):
|
|
|
|
|
def emit(self, record):
|
|
|
|
|
raise Exception("This shouldn't have happened!")
|
|
|
|
|
|
|
|
|
|
logger = logging.getLogger('django.request')
|
|
|
|
|
test_handler = TestHandler()
|
|
|
|
|
old_log_level = logger.level
|
|
|
|
|
try:
|
|
|
|
|
logger.addHandler(test_handler)
|
|
|
|
|
logger.setLevel(logging.WARNING)
|
|
|
|
|
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
2013-09-08 19:20:01 +00:00
|
|
|
view(req)
|
2013-05-18 11:09:38 +00:00
|
|
|
finally:
|
|
|
|
|
logger.removeHandler(test_handler)
|
|
|
|
|
logger.setLevel(old_log_level)
|
2014-03-04 00:52:28 +00:00
|
|
|
|
|
|
|
|
def test_csrf_cookie_age(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
CSRF cookie age can be set using settings.CSRF_COOKIE_AGE.
|
2014-03-04 00:52:28 +00:00
|
|
|
"""
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
|
|
|
|
|
MAX_AGE = 123
|
|
|
|
|
with self.settings(CSRF_COOKIE_NAME='csrfcookie',
|
|
|
|
|
CSRF_COOKIE_DOMAIN='.example.com',
|
|
|
|
|
CSRF_COOKIE_AGE=MAX_AGE,
|
|
|
|
|
CSRF_COOKIE_PATH='/test/',
|
|
|
|
|
CSRF_COOKIE_SECURE=True,
|
|
|
|
|
CSRF_COOKIE_HTTPONLY=True):
|
|
|
|
|
# token_view calls get_token() indirectly
|
|
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
max_age = resp2.cookies.get('csrfcookie').get('max-age')
|
|
|
|
|
self.assertEqual(max_age, MAX_AGE)
|
|
|
|
|
|
|
|
|
|
def test_csrf_cookie_age_none(self):
|
|
|
|
|
"""
|
2015-09-04 19:58:15 +00:00
|
|
|
CSRF cookie age does not have max age set and therefore uses
|
|
|
|
|
session-based cookies.
|
2014-03-04 00:52:28 +00:00
|
|
|
"""
|
|
|
|
|
req = self._get_GET_no_csrf_cookie_request()
|
|
|
|
|
|
|
|
|
|
MAX_AGE = None
|
|
|
|
|
with self.settings(CSRF_COOKIE_NAME='csrfcookie',
|
|
|
|
|
CSRF_COOKIE_DOMAIN='.example.com',
|
|
|
|
|
CSRF_COOKIE_AGE=MAX_AGE,
|
|
|
|
|
CSRF_COOKIE_PATH='/test/',
|
|
|
|
|
CSRF_COOKIE_SECURE=True,
|
|
|
|
|
CSRF_COOKIE_HTTPONLY=True):
|
|
|
|
|
# token_view calls get_token() indirectly
|
|
|
|
|
CsrfViewMiddleware().process_view(req, token_view, (), {})
|
|
|
|
|
resp = token_view(req)
|
|
|
|
|
|
|
|
|
|
resp2 = CsrfViewMiddleware().process_response(req, resp)
|
|
|
|
|
max_age = resp2.cookies.get('csrfcookie').get('max-age')
|
|
|
|
|
self.assertEqual(max_age, '')
|
2014-06-25 10:52:25 +00:00
|
|
|
|
|
|
|
|
def test_post_data_read_failure(self):
|
|
|
|
|
"""
|
|
|
|
|
#20128 -- IOErrors during POST data reading should be caught and
|
|
|
|
|
treated as if the POST data wasn't there.
|
|
|
|
|
"""
|
|
|
|
|
class CsrfPostRequest(HttpRequest):
|
|
|
|
|
"""
|
|
|
|
|
HttpRequest that can raise an IOError when accessing POST data
|
|
|
|
|
"""
|
|
|
|
|
def __init__(self, token, raise_error):
|
|
|
|
|
super(CsrfPostRequest, self).__init__()
|
|
|
|
|
self.method = 'POST'
|
|
|
|
|
|
|
|
|
|
self.raise_error = False
|
|
|
|
|
self.COOKIES[settings.CSRF_COOKIE_NAME] = token
|
|
|
|
|
self.POST['csrfmiddlewaretoken'] = token
|
|
|
|
|
self.raise_error = raise_error
|
|
|
|
|
|
|
|
|
|
def _load_post_and_files(self):
|
|
|
|
|
raise IOError('error reading input data')
|
|
|
|
|
|
|
|
|
|
def _get_post(self):
|
|
|
|
|
if self.raise_error:
|
|
|
|
|
self._load_post_and_files()
|
|
|
|
|
return self._post
|
|
|
|
|
|
|
|
|
|
def _set_post(self, post):
|
|
|
|
|
self._post = post
|
|
|
|
|
|
|
|
|
|
POST = property(_get_post, _set_post)
|
|
|
|
|
|
Fixed #20869 -- made CSRF tokens change every request by salt-encrypting them
Note that the cookie is not changed every request, just the token retrieved
by the `get_token()` method (used also by the `{% csrf_token %}` tag).
While at it, made token validation strict: Where, before, any length was
accepted and non-ASCII chars were ignored, we now treat anything other than
`[A-Za-z0-9]{64}` as invalid (except for 32-char tokens, which, for
backwards-compatibility, are accepted and replaced by 64-char ones).
Thanks Trac user patrys for reporting, github user adambrenecki
for initial patch, Tim Graham for help, and Curtis Maloney,
Collin Anderson, Florian Apolloner, Markus Holtermann & Jon Dufresne
for reviews.
2015-11-07 16:35:45 +00:00
|
|
|
token = ('ABC' + self._csrf_id)[:CSRF_TOKEN_LENGTH]
|
2014-06-25 10:52:25 +00:00
|
|
|
|
|
|
|
|
req = CsrfPostRequest(token, raise_error=False)
|
|
|
|
|
resp = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
2015-01-06 07:48:01 +00:00
|
|
|
self.assertIsNone(resp)
|
2014-06-25 10:52:25 +00:00
|
|
|
|
|
|
|
|
req = CsrfPostRequest(token, raise_error=True)
|
2016-06-03 00:24:48 +00:00
|
|
|
with patch_logger('django.security.csrf', 'warning') as logger_calls:
|
|
|
|
|
resp = CsrfViewMiddleware().process_view(req, post_form_view, (), {})
|
|
|
|
|
self.assertEqual(resp.status_code, 403)
|
|
|
|
|
self.assertEqual(logger_calls[0], 'Forbidden (%s): ' % REASON_BAD_TOKEN)
|
