Fixed a settings leak possibility in the date template filter.
This is a security fix.
This commit is contained in:
parent
710e11d076
commit
316bc3fc94
|
@ -30,6 +30,24 @@ ISO_INPUT_FORMATS = {
|
|||
}
|
||||
|
||||
|
||||
FORMAT_SETTINGS = frozenset([
|
||||
'DECIMAL_SEPARATOR',
|
||||
'THOUSAND_SEPARATOR',
|
||||
'NUMBER_GROUPING',
|
||||
'FIRST_DAY_OF_WEEK',
|
||||
'MONTH_DAY_FORMAT',
|
||||
'TIME_FORMAT',
|
||||
'DATE_FORMAT',
|
||||
'DATETIME_FORMAT',
|
||||
'SHORT_DATE_FORMAT',
|
||||
'SHORT_DATETIME_FORMAT',
|
||||
'YEAR_MONTH_FORMAT',
|
||||
'DATE_INPUT_FORMATS',
|
||||
'TIME_INPUT_FORMATS',
|
||||
'DATETIME_INPUT_FORMATS',
|
||||
])
|
||||
|
||||
|
||||
def reset_format_cache():
|
||||
"""Clear any cached formats.
|
||||
|
||||
|
@ -92,6 +110,8 @@ def get_format(format_type, lang=None, use_l10n=None):
|
|||
be localized (or not), overriding the value of settings.USE_L10N.
|
||||
"""
|
||||
format_type = force_str(format_type)
|
||||
if format_type not in FORMAT_SETTINGS:
|
||||
return format_type
|
||||
if use_l10n or (use_l10n is None and settings.USE_L10N):
|
||||
if lang is None:
|
||||
lang = get_language()
|
||||
|
|
|
@ -4,7 +4,20 @@ Django 1.7.11 release notes
|
|||
|
||||
*Under development*
|
||||
|
||||
Django 1.7.11 fixes a data loss bug in 1.7.10.
|
||||
Django 1.7.11 fixes a security issue and a data loss bug in 1.7.10.
|
||||
|
||||
Fixed settings leak possibility in ``date`` template filter
|
||||
===========================================================
|
||||
|
||||
If an application allows users to specify an unvalidated format for dates and
|
||||
passes this format to the :tfilter:`date` filter, e.g.
|
||||
``{{ last_updated|date:user_date_format }}``, then a malicious user could
|
||||
obtain any secret in the application's settings by specifying a settings key
|
||||
instead of a date format. e.g. ``"SECRET_KEY"`` instead of ``"j/m/Y"``.
|
||||
|
||||
To remedy this, the underlying function used by the ``date`` template filter,
|
||||
``django.utils.formats.get_format()``, now only allows accessing the date/time
|
||||
formatting settings.
|
||||
|
||||
Bugfixes
|
||||
========
|
||||
|
|
|
@ -4,11 +4,24 @@ Django 1.8.7 release notes
|
|||
|
||||
*Under development*
|
||||
|
||||
Django 1.8.7 fixes several bugs in 1.8.6.
|
||||
Django 1.8.7 fixes a security issue and several bugs in 1.8.6.
|
||||
|
||||
Additionally, Django's vendored version of six, :mod:`django.utils.six`, has
|
||||
been upgraded to the latest release (1.10.0).
|
||||
|
||||
Fixed settings leak possibility in ``date`` template filter
|
||||
===========================================================
|
||||
|
||||
If an application allows users to specify an unvalidated format for dates and
|
||||
passes this format to the :tfilter:`date` filter, e.g.
|
||||
``{{ last_updated|date:user_date_format }}``, then a malicious user could
|
||||
obtain any secret in the application's settings by specifying a settings key
|
||||
instead of a date format. e.g. ``"SECRET_KEY"`` instead of ``"j/m/Y"``.
|
||||
|
||||
To remedy this, the underlying function used by the ``date`` template filter,
|
||||
``django.utils.formats.get_format()``, now only allows accessing the date/time
|
||||
formatting settings.
|
||||
|
||||
Bugfixes
|
||||
========
|
||||
|
||||
|
|
|
@ -1249,6 +1249,9 @@ class FormattingTests(SimpleTestCase):
|
|||
'<input id="id_cents_paid" name="cents_paid" type="hidden" value="59,47" />'
|
||||
)
|
||||
|
||||
def test_format_arbitrary_settings(self):
|
||||
self.assertEqual(get_format('DEBUG'), 'DEBUG')
|
||||
|
||||
|
||||
class MiscTests(SimpleTestCase):
|
||||
|
||||
|
|
Loading…
Reference in New Issue