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, но некоторые проекты могут подклассифицировать его и при необходимости увеличить рабочий коэффициент.

Предупреждение будет выдано для любых сторонних хэшеров паролей, которые не реализуют метод harden_runtime().

Если в вашей базе данных есть разные хэши паролей (например, хэши SHA1 от пользователей, которые не вошли в систему с тех пор, как хэшер по умолчанию переключился на PBKDF2 в Django 1.4), разница во времени запроса на вход для этих пользователей может быть еще больше, и это исправление не устраняет эту разницу (или любую разницу при смене хэшей). Возможно, вы сможете обновить эти хеши, чтобы предотвратить временную атаку в этом случае.

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

• Исправлен сбой в 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).