Примечания к выпуску Django 1.4.21¶
8 июля 2015
Django 1.4.21 исправляет несколько проблем безопасности в версии 1.4.20.
Возможность отказа в обслуживании путем заполнения хранилища сеансов¶
В предыдущих версиях Django сессионные бэкенды создавали новую пустую запись в хранилище сессий при каждом обращении к request.session и наличии сеансового ключа, предоставленного в cookies запроса, в котором еще не было сеансовой записи. Это могло позволить злоумышленнику легко создать множество новых записей сессии, просто посылая повторные запросы с неизвестными ключами сессии, потенциально заполняя хранилище сессий или вызывая вытеснение записей сессии других пользователей.
Встроенные бэкенды сессий теперь создают запись сессии только в том случае, если сессия действительно изменена; пустые записи сессий не создаются. Таким образом, потенциальный 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() и проверяет, не возникло ли исключение.