Примечания к выпуску Django 1.9.3¶
1 марта 2016 г.
Django 1.9.3 исправляет две проблемы безопасности и несколько ошибок в 1.9.2.
CVE-2016-2512: Вредоносное перенаправление и возможная XSS-атака через URL-адреса перенаправления, заданные пользователем и содержащие базовый аутентификатор¶
Django полагается на ввод пользователя в некоторых случаях (например, django.contrib.auth.views.login()
и i18n), чтобы перенаправить пользователя на URL «при успехе». Проверка безопасности для этих перенаправлений (а именно django.utils.http.is_safe_url()
) считала некоторые URL с базовыми учетными данными аутентификации «безопасными», когда они не должны были быть таковыми.
Например, URL типа http://mysite.example.com\@attacker.com
будет считаться безопасным, если хостом запроса является http://mysite.example.com
, но перенаправление на этот URL отправляет пользователя на attacker.com
.
Кроме того, если разработчик полагается на is_safe_url()
для обеспечения безопасных целей перенаправления и помещает такой URL в ссылку, он может пострадать от XSS-атаки.
CVE-2016-2513: Перечисление пользователей через разницу во времени при обновлении фактора работы хешера паролей¶
В каждой основной версии Django, начиная с версии 1.6, количество итераций по умолчанию для пароля PBKDF2PasswordHasher
и его подклассов увеличивалось. Это улучшает безопасность пароля по мере увеличения скорости аппаратного обеспечения, однако, это также создает разницу во времени между запросом на вход для пользователя с паролем, закодированным в более старом числе итераций, и запросом на вход для несуществующего пользователя (который выполняет хешер с числом итераций по умолчанию начиная с Django 1.6).
Это касается только тех пользователей, которые не входили в систему после увеличения итераций. При первом входе пользователя после увеличения итераций его пароль будет обновлен с учетом новых итераций, и разницы во времени больше не будет.
Новый метод BasePasswordHasher.harden_runtime()
позволяет хешерам преодолеть разрыв во времени между рабочим коэффициентом (например, итерациями), указанным в существующих закодированных паролях, и рабочим коэффициентом хешера по умолчанию. Этот метод реализован для PBKDF2PasswordHasher
и BCryptPasswordHasher
. Количество раундов для последнего хешера не изменилось со времен Django 1.4, но некоторые проекты могут подклассифицировать его и увеличивать рабочий коэффициент по мере необходимости.
Предупреждение будет выдано для любого метода third-party password hashers that don’t implement a harden_runtime()
.
Если в вашей базе данных есть разные хэши паролей (например, SHA1-хэши от пользователей, которые не входили в систему после того, как хэшер по умолчанию перешел на PBKDF2 в Django 1.4), разница во времени запроса на вход для этих пользователей может быть еще больше, и это исправление не исправляет эту разницу (или любую разницу при смене хэшеров). Вы можете использовать upgrade those hashes для предотвращения атаки по времени в этом случае.
Исправления¶
- Пропуск проверок URL (новое в 1.9), если параметр
ROOT_URLCONF
не определен (#26155). - Исправлена ошибка в PostgreSQL, которая не позволяла использовать
TIME_ZONE=None
иUSE_TZ=False
(#26177). - Добавлена системная проверка на столкновение имен запросов скрытых отношений (#26162).
- Исправлена регрессия для случаев, когда
ForeignObject.get_extra_descriptor_filter()
возвращало объектQ
(#26153). - Исправлена регрессия с поиском
__in=qs
дляForeignKey
с установленнымto_field
(#26196). - Сделаны
forms.FileField
иutils.translation.lazy_number()
маринованными (#26212). - Исправлена сериализация
RangeField
иArrayField
со значениямиNone
(#26215). - Исправлена ошибка при фильтрации по
Decimal
вRawQuery
(#26219). - Разрешены тире в доменных именах верхнего уровня URL, проверяемых
URLValidator
, чтобы исправить ошибку в Django 1.8 (#26204). - Исправлены некоторые сбойные шиммы deprecation в
SimpleTemplateResponse
, которые регрессировали в Django 1.9 (#26253). - Исправлено
BoundField
, чтобы разрешить нарезку субвиджетов (#26267). - Изменено сообщение администратора «разрешение отклонено» в шаблоне входа, чтобы использовать
get_username
вместоusername
для поддержки пользовательских моделей пользователей (#26231). - Исправлена ошибка при передаче несуществующего имени шаблона в метод
load_template()
кэшированного загрузчика шаблонов (#26280). - Предотвращение совместного использования кэша экземплярами
ContentTypeManager
(#26286). - Исправлено изменение в Django 1.9.2 (#25858), из-за которого относительные ленивые отношения, определенные в абстрактных моделях, не разрешались в соответствии с
app_label
(#26186) их конкретной модели.