Примечания к выпуску Django 1.7.9 ¶
8 июля 2015 г.
Django 1.7.9 исправляет несколько проблем безопасности и ошибок в 1.7.8.
Возможность отказа в обслуживании путем заполнения хранилища сессий ¶
В предыдущих версиях 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()преобразования значения с использованием и проверки того, возникло ли исключение.
