• 3.1
  • 3.2
  • 6.1
  • Версия документации: 5.0

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

8 июля 2015 г.

Django 1.4.21 исправляет несколько проблем безопасности в версии 1.4.20.

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

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

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

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

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

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

validate_ipv4_address(), validate_slug() и URLValidator и их использование в соответствующих полях формы GenericIPAddresseField, IPAddressField, Также затронуты SlugField и URLField.

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

Back to Top