Возможность отказа в обслуживании путем заполнения хранилища сеансов¶

В предыдущих версиях Django серверные части сеанса создавали новую пустую запись в хранилище сеансов каждый раз при доступе к request.session, и в файлах cookie запроса был указан сеансовый ключ, который еще не имел записи сеанса. Это может позволить злоумышленнику легко создать множество новых записей сеанса, просто отправляя повторяющиеся запросы с неизвестными ключами сеанса, что потенциально может заполнить хранилище сеансов или привести к удалению записей сеансов других пользователей.

Встроенные серверные части сеанса теперь создают запись сеанса только в том случае, если сеанс действительно был изменен; пустые записи сеанса не создаются. Таким образом, этот потенциальный DoS теперь возможен только в том случае, если сайт решит предоставить анонимным пользователям представление, изменяющее сеанс.

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

Возможность внедрения заголовка, поскольку валидаторы принимают символы новой строки во входных данных.¶

Некоторые из встроенных валидаторов Django (EmailValidator, самое серьезное) не запрещали символы новой строки (из-за использования $ вместо \Z в регулярных выражениях). Если вы используете значения с символами новой строки в ответах HTTP или заголовках электронных писем, вы можете пострадать от атак с внедрением заголовков. Сам Django не уязвим, поскольку HttpResponse и утилиты отправки почты в django.core.mail запрещают переводы строк в заголовках HTTP и SMTP соответственно. Хотя валидаторы были исправлены в Django, если вы создаете HTTP-ответы или сообщения электронной почты другими способами, рекомендуется убедиться, что эти методы также запрещают переводы строк. Вы также можете проверить, что любые существующие данные в вашем приложении не содержат неожиданных символов новой строки.

validate_ipv4_address(), validate_slug() и URLValidator также затронуты, однако, начиная с Django 1.6, GenericIPAddresseField, Поля формы IPAddressField, SlugField и URLField, которые используют эти валидаторы, удаляют входные данные, поэтому возможность ввода новых строк в ваши данные существует только в том случае, если вы используете эти валидаторы вне полей формы.

Недокументированная, внутренне неиспользуемая функция validate_integer() теперь более строгая, поскольку она проверяет использование регулярного выражения вместо простого приведения значения с помощью int() и проверки возникновения исключения.

Возможность отказа в обслуживании при проверке URL-адреса¶

URLValidator включал регулярное выражение, которое очень медленно вычислялось на основе некоторых недопустимых входных данных. Это регулярное выражение было упрощено и оптимизировано.

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

• Исправлен BaseRangeField.prepare_value() для использования каждого метода prepare_value() из base_field (#24841).

• Исправлен сбой во время выполнения makemigrations, если в модуле миграции либо отсутствует __init__.py, либо он представляет собой файл (#24848).

• Исправлен QuerySet.exists(), возвращающий неверные результаты после аннотации с Count() (#24835).

• Исправлен HStoreField.has_changed() (#24844).

• Отменена оптимизация процессора контекста шаблона CSRF, которая вызывала регрессию (#24836).

• Исправлена ​​регрессия, из-за которой процессоры контекста шаблона перезаписывали переменные, установленные в RequestContext после его создания (#24847).

• Предотвращена потеря свойств столбца null/not null во время переименования полей баз данных MySQL (#24817).

• Исправлен сбой при использовании обратного отношения «один к одному» в ModelAdmin.list_display (:ticket:24851).

• Исправлено цитирование SQL при переименовании поля в AutoField в PostgreSQL (#24892).

• Исправлено отсутствие ограничения уникальности при изменении поля с primary_key=True на unique=True (#24893).

• Исправлено травление набора запросов при использовании prefetch_related() после удаления объектов (#24831).

• Разрешено использование choices продолжительностью более 1 дня с DurationField (#24897).

• Исправлен сбой при загрузке сжатых миграций из двух приложений с зависимостью между ними, когда замененные миграции зависимого приложения применяются частично (#24895).

• Исправлена ​​запись примененного статуса для сжатых (замещающих) миграций (#24628).

• Исправлены аннотации набора запросов при использовании выражений Case с exclude() (#24833).

• Исправлено продвижение объединения для нескольких выражений Case. Аннотирование запроса несколькими выражениями Case может неожиданно отфильтровать результаты (#24924).

• Исправлено использование преобразований в подзапросах (#24744).

• Исправлен SimpleTestCase.assertRaisesMessage() в Python 2.7.10 (#24903).

• Обеспечена лучшая обратная совместимость для аргумента verbosity в командах управления optparse путем приведения его к целому числу (#24769).

• Исправлен prefetch_related() в базах данных, отличных от PostgreSQL, для моделей, использующих первичные ключи UUID (#24912).

• Исправлено удаление ограничений unique_together в MySQL (#24972).

• Исправлен сбой при загрузке изображений с типами MIME, которые Pillow не обнаруживает, например растровыми изображениями, в form.ImageField (#24948).

• Исправлена ​​регрессия при удалении модели через администратора, у которой есть GenericRelation с именем linked_query_name (#24940).

• Перераспределены значения, отличные от ASCII, для ForeignKey.related_name в Python 3 путем исправления ложного срабатывания системной проверки (#25016).

• Исправлены встроенные формы, использующие родительский объект с первичным ключом UUIDField и дочерний объект с первичным ключом AutoField (:ticket:24958).

• Исправлена ​​регрессия в фильтре шаблонов unordered_list на некоторых входных данных (#25031).

• Исправлена ​​регрессия в URLValidator, которая делала недействительными TLD Punycode (#25059).

• Улучшен опрос pyinotify runserver (#23882).