Примечания к выпуску 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) их конкретной модели.
Вернуться на верх