Примечания к выпуску 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()преобразования значения с использованием и проверки того, возникло ли исключение.