2012-08-14 02:56:05 +08:00
|
|
|
# -*- coding: utf-8 -*-
|
2012-06-08 00:08:47 +08:00
|
|
|
from __future__ import unicode_literals
|
|
|
|
|
2012-08-14 15:45:53 +08:00
|
|
|
import datetime
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
import os
|
2012-08-18 16:37:06 +08:00
|
|
|
import pickle
|
2011-06-01 21:47:00 +08:00
|
|
|
import re
|
2011-04-02 21:26:19 +08:00
|
|
|
import warnings
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2011-06-01 21:47:00 +08:00
|
|
|
from django import http
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
from django.conf import settings
|
2011-08-13 21:51:34 +08:00
|
|
|
from django.contrib.formtools import preview, utils
|
2007-11-30 00:32:23 +08:00
|
|
|
from django.test import TestCase
|
2012-09-26 00:38:47 +08:00
|
|
|
from django.test.html import parse_html
|
2012-04-01 00:03:09 +08:00
|
|
|
from django.test.utils import override_settings
|
2012-12-08 18:13:52 +08:00
|
|
|
from django.utils._os import upath
|
2010-10-11 20:55:17 +08:00
|
|
|
from django.utils import unittest
|
2007-11-30 00:32:23 +08:00
|
|
|
|
2011-08-13 21:51:34 +08:00
|
|
|
from django.contrib.formtools.tests.wizard import *
|
2011-06-01 21:47:00 +08:00
|
|
|
from django.contrib.formtools.tests.forms import *
|
|
|
|
|
2010-12-04 15:28:12 +08:00
|
|
|
success_string = "Done was called!"
|
2012-08-14 03:07:51 +08:00
|
|
|
success_string_encoded = success_string.encode()
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
2007-11-30 00:32:23 +08:00
|
|
|
class TestFormPreview(preview.FormPreview):
|
2010-11-21 21:47:38 +08:00
|
|
|
def get_context(self, request, form):
|
|
|
|
context = super(TestFormPreview, self).get_context(request, form)
|
|
|
|
context.update({'custom_context': True})
|
|
|
|
return context
|
|
|
|
|
|
|
|
def get_initial(self, request):
|
|
|
|
return {'field1': 'Works!'}
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
def done(self, request, cleaned_data):
|
|
|
|
return http.HttpResponse(success_string)
|
|
|
|
|
2012-04-01 00:03:09 +08:00
|
|
|
@override_settings(
|
|
|
|
TEMPLATE_DIRS=(
|
2012-12-08 18:13:52 +08:00
|
|
|
os.path.join(os.path.dirname(upath(__file__)), 'templates'),
|
2012-04-01 00:03:09 +08:00
|
|
|
),
|
|
|
|
)
|
|
|
|
class PreviewTests(TestCase):
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
urls = 'django.contrib.formtools.tests.urls'
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
def setUp(self):
|
2011-08-13 21:51:34 +08:00
|
|
|
super(PreviewTests, self).setUp()
|
2007-11-30 00:32:23 +08:00
|
|
|
# Create a FormPreview instance to share between tests
|
|
|
|
self.preview = preview.FormPreview(TestForm)
|
|
|
|
input_template = '<input type="hidden" name="%s" value="%s" />'
|
|
|
|
self.input = input_template % (self.preview.unused_name('stage'), "%d")
|
2012-06-08 00:08:47 +08:00
|
|
|
self.test_data = {'field1': 'foo', 'field1_': 'asdf'}
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
def test_unused_name(self):
|
|
|
|
"""
|
|
|
|
Verifies name mangling to get uniue field name.
|
|
|
|
"""
|
|
|
|
self.assertEqual(self.preview.unused_name('field1'), 'field1__')
|
|
|
|
|
|
|
|
def test_form_get(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form retrieval.
|
|
|
|
|
|
|
|
Use the client library to see if we can sucessfully retrieve
|
|
|
|
the form (mostly testing the setup ROOT_URLCONF
|
|
|
|
process). Verify that an additional hidden input field
|
|
|
|
is created to manage the stage.
|
|
|
|
|
|
|
|
"""
|
2011-06-01 21:47:00 +08:00
|
|
|
response = self.client.get('/preview/')
|
2007-11-30 00:32:23 +08:00
|
|
|
stage = self.input % 1
|
|
|
|
self.assertContains(response, stage, 1)
|
2011-03-03 23:04:39 +08:00
|
|
|
self.assertEqual(response.context['custom_context'], True)
|
|
|
|
self.assertEqual(response.context['form'].initial, {'field1': 'Works!'})
|
2007-11-30 00:32:23 +08:00
|
|
|
|
|
|
|
def test_form_preview(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form preview rendering.
|
|
|
|
|
|
|
|
Use the client library to POST to the form to see if a preview
|
|
|
|
is returned. If we do get a form back check that the hidden
|
|
|
|
value is correctly managing the state of the form.
|
|
|
|
|
|
|
|
"""
|
|
|
|
# Pass strings for form submittal and add stage variable to
|
|
|
|
# show we previously saw first stage of the form.
|
2012-08-14 15:45:53 +08:00
|
|
|
self.test_data.update({'stage': 1, 'date1': datetime.date(2006, 10, 25)})
|
2011-06-01 21:47:00 +08:00
|
|
|
response = self.client.post('/preview/', self.test_data)
|
2007-11-30 00:32:23 +08:00
|
|
|
# Check to confirm stage is set to 2 in output form.
|
|
|
|
stage = self.input % 2
|
|
|
|
self.assertContains(response, stage, 1)
|
|
|
|
|
|
|
|
def test_form_submit(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form submittal.
|
|
|
|
|
|
|
|
Use the client library to POST to the form with stage set to 3
|
|
|
|
to see if our forms done() method is called. Check first
|
|
|
|
without the security hash, verify failure, retry with security
|
|
|
|
hash and verify sucess.
|
|
|
|
|
|
|
|
"""
|
|
|
|
# Pass strings for form submittal and add stage variable to
|
|
|
|
# show we previously saw first stage of the form.
|
2012-08-14 15:45:53 +08:00
|
|
|
self.test_data.update({'stage': 2, 'date1': datetime.date(2006, 10, 25)})
|
2011-06-01 21:47:00 +08:00
|
|
|
response = self.client.post('/preview/', self.test_data)
|
2012-08-14 03:07:51 +08:00
|
|
|
self.assertNotEqual(response.content, success_string_encoded)
|
2008-08-27 04:19:12 +08:00
|
|
|
hash = self.preview.security_hash(None, TestForm(self.test_data))
|
|
|
|
self.test_data.update({'hash': hash})
|
2011-06-01 21:47:00 +08:00
|
|
|
response = self.client.post('/preview/', self.test_data)
|
2012-08-14 03:07:51 +08:00
|
|
|
self.assertEqual(response.content, success_string_encoded)
|
2008-08-27 04:19:12 +08:00
|
|
|
|
|
|
|
def test_bool_submit(self):
|
|
|
|
"""
|
|
|
|
Test contrib.formtools.preview form submittal when form contains:
|
|
|
|
BooleanField(required=False)
|
|
|
|
|
|
|
|
Ticket: #6209 - When an unchecked BooleanField is previewed, the preview
|
|
|
|
form's hash would be computed with no value for ``bool1``. However, when
|
|
|
|
the preview form is rendered, the unchecked hidden BooleanField would be
|
|
|
|
rendered with the string value 'False'. So when the preview form is
|
|
|
|
resubmitted, the hash would be computed with the value 'False' for
|
|
|
|
``bool1``. We need to make sure the hashes are the same in both cases.
|
|
|
|
|
|
|
|
"""
|
|
|
|
self.test_data.update({'stage':2})
|
|
|
|
hash = self.preview.security_hash(None, TestForm(self.test_data))
|
2012-06-08 00:08:47 +08:00
|
|
|
self.test_data.update({'hash': hash, 'bool1': 'False'})
|
2012-05-04 00:19:18 +08:00
|
|
|
with warnings.catch_warnings(record=True):
|
|
|
|
response = self.client.post('/preview/', self.test_data)
|
2012-08-14 03:07:51 +08:00
|
|
|
self.assertEqual(response.content, success_string_encoded)
|
2007-11-30 00:32:23 +08:00
|
|
|
|
2011-03-31 01:35:01 +08:00
|
|
|
def test_form_submit_good_hash(self):
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
"""
|
2011-03-31 01:35:01 +08:00
|
|
|
Test contrib.formtools.preview form submittal, using a correct
|
|
|
|
hash
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
"""
|
|
|
|
# Pass strings for form submittal and add stage variable to
|
|
|
|
# show we previously saw first stage of the form.
|
|
|
|
self.test_data.update({'stage':2})
|
2011-06-01 21:47:00 +08:00
|
|
|
response = self.client.post('/preview/', self.test_data)
|
2012-08-14 03:07:51 +08:00
|
|
|
self.assertNotEqual(response.content, success_string_encoded)
|
2011-03-31 01:35:01 +08:00
|
|
|
hash = utils.form_hmac(TestForm(self.test_data))
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
self.test_data.update({'hash': hash})
|
2011-06-01 21:47:00 +08:00
|
|
|
response = self.client.post('/preview/', self.test_data)
|
2012-08-14 03:07:51 +08:00
|
|
|
self.assertEqual(response.content, success_string_encoded)
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
|
|
|
|
2011-03-31 01:35:01 +08:00
|
|
|
def test_form_submit_bad_hash(self):
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
"""
|
2011-03-31 01:35:01 +08:00
|
|
|
Test contrib.formtools.preview form submittal does not proceed
|
|
|
|
if the hash is incorrect.
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
"""
|
|
|
|
# Pass strings for form submittal and add stage variable to
|
|
|
|
# show we previously saw first stage of the form.
|
|
|
|
self.test_data.update({'stage':2})
|
2011-06-01 21:47:00 +08:00
|
|
|
response = self.client.post('/preview/', self.test_data)
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
self.assertEqual(response.status_code, 200)
|
2012-08-14 03:07:51 +08:00
|
|
|
self.assertNotEqual(response.content, success_string_encoded)
|
2011-03-31 01:35:01 +08:00
|
|
|
hash = utils.form_hmac(TestForm(self.test_data)) + "bad"
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
self.test_data.update({'hash': hash})
|
2011-06-01 21:47:00 +08:00
|
|
|
response = self.client.post('/previewpreview/', self.test_data)
|
2012-08-14 03:07:51 +08:00
|
|
|
self.assertNotEqual(response.content, success_string_encoded)
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
|
|
|
|
|
|
|
|
class FormHmacTests(unittest.TestCase):
|
|
|
|
|
|
|
|
def test_textfield_hash(self):
|
|
|
|
"""
|
|
|
|
Regression test for #10034: the hash generation function should ignore
|
|
|
|
leading/trailing whitespace so as to be friendly to broken browsers that
|
|
|
|
submit it (usually in textareas).
|
|
|
|
"""
|
2012-08-14 02:56:05 +08:00
|
|
|
f1 = HashTestForm({'name': 'joe', 'bio': 'Speaking español.'})
|
|
|
|
f2 = HashTestForm({'name': ' joe', 'bio': 'Speaking español. '})
|
Fixed #14445 - Use HMAC and constant-time comparison functions where needed.
All adhoc MAC applications have been updated to use HMAC, using SHA1 to
generate unique keys for each application based on the SECRET_KEY, which is
common practice for this situation. In all cases, backwards compatibility
with existing hashes has been maintained, aiming to phase this out as per
the normal deprecation process. In this way, under most normal
circumstances the old hashes will have expired (e.g. by session expiration
etc.) before they become invalid.
In the case of the messages framework and the cookie backend, which was
already using HMAC, there is the possibility of a backwards incompatibility
if the SECRET_KEY is shorter than the default 50 bytes, but the low
likelihood and low impact meant compatibility code was not worth it.
All known instances where tokens/hashes were compared using simple string
equality, which could potentially open timing based attacks, have also been
fixed using a constant-time comparison function.
There are no known practical attacks against the existing implementations,
so these security improvements will not be backported.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@14218 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2010-10-15 04:54:30 +08:00
|
|
|
hash1 = utils.form_hmac(f1)
|
|
|
|
hash2 = utils.form_hmac(f2)
|
|
|
|
self.assertEqual(hash1, hash2)
|
|
|
|
|
|
|
|
def test_empty_permitted(self):
|
|
|
|
"""
|
|
|
|
Regression test for #10643: the security hash should allow forms with
|
|
|
|
empty_permitted = True, or forms where data has not changed.
|
|
|
|
"""
|
|
|
|
f1 = HashTestBlankForm({})
|
|
|
|
f2 = HashTestForm({}, empty_permitted=True)
|
|
|
|
hash1 = utils.form_hmac(f1)
|
|
|
|
hash2 = utils.form_hmac(f2)
|
|
|
|
self.assertEqual(hash1, hash2)
|