Примечания к выпуску Django 1.8.10 ¶
1 марта 2016 г.
Django 1.8.10 исправляет две проблемы безопасности и несколько ошибок в 1.8.9.
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, но некоторые проекты могут создавать подклассы и увеличивать коэффициент работы по мере необходимости.
Предупреждение будет выделяться для любых третьих лиц паролей hashers , которые не реализуют в harden_runtime()
метод.
Если у вас есть разные хэши паролей в вашей базе данных (например, хэши SHA1 от пользователей, которые не вошли в систему с тех пор, как хешер по умолчанию переключился на PBKDF2 в Django 1.4), разница во времени запроса входа для этих пользователей может быть еще больше, и это fix не устраняет эту разницу (или любую разницу при изменении хешеров). Возможно, вы сможете обновить эти хэши, чтобы предотвратить временную атаку в этом случае.
Исправления ¶
- Исправлен сбой в 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 ).