Примечания к выпуску Django 1.8.10¶

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 для предотвращения атаки по времени в этом случае.

Исправления¶

• Исправлена ошибка в PostgreSQL, которая не позволяла использовать TIME_ZONE=None и USE_TZ=False (#26177).
• Добавлена системная проверка на столкновение имен запросов скрытых отношений (#26162).
• Сделаны forms.FileField и utils.translation.lazy_number() маринованными (#26212).
• Исправлена сериализация RangeField и ArrayField со значениями None (#26215).
• Разрешены тире в доменных именах верхнего уровня URL, проверяемых URLValidator, чтобы исправить ошибку в Django 1.8 (#26204).
• Исправлено BoundField, чтобы разрешить срезы подвиджетов (#26267).
• Предотвращение совместного использования кэша экземплярами ContentTypeManager (#26286).