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

19 февраля 2013 г.

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

Это четвертый выпуск исправления ошибок / безопасности в серии Django 1.4.

Отравление заголовка хоста

Некоторые части Django - независимо от приложений, написанных конечным пользователем - используют полные URL-адреса, включая доменное имя, которые генерируются из заголовка HTTP Host. Документация Django в течение некоторого времени содержала примечания, советующие пользователям, как настроить веб-серверы, чтобы гарантировать, что только действительные заголовки Host могут достигать приложения Django. Однако нам сообщили, что даже при рекомендуемых конфигурациях веб-серверов все еще доступны методы, позволяющие обманом заставить многие обычные веб-серверы предоставить приложению неправильный и, возможно, вредоносный заголовок Host.

По этой причине Django 1.4.4 добавляет новый параметр, ALLOWED_HOSTS содержащий явный список допустимых имен хостов / доменов для этого сайта. Запрос с заголовком Host, не совпадающим с записью в этом списке, будет инициирован, SuspiciousOperation если request.get_host() будет вызван. Для получения полной информации см. Документацию по ALLOWED_HOSTS настройке.

Значение по умолчанию для этого параметра в Django 1.4.4 - ['*'] (соответствует любому хосту) для обратной совместимости, но мы настоятельно рекомендуем всем сайтам устанавливать более ограничительное значение.

Эта проверка хоста отключена, когда DEBUG есть True или при запуске тестов.

Десериализация XML

Анализатор XML в стандартной библиотеке Python уязвим для ряда атак через внешние сущности и расширение сущностей. Django использует этот парсер для десериализации фикстур базы данных в формате XML. Этот десериализатор не предназначен для использования с ненадежными данными, но в целях обеспечения безопасности в Django 1.4.4 десериализатор XML отказывается анализировать XML-документ с помощью DTD (определение DOCTYPE), что закрывает эти пути атаки.

Этими проблемами в стандартной библиотеке Python являются CVE-2013-1664 и CVE-2013-1665. Дополнительную информацию можно получить в группе безопасности Python .

XML-сериализатор Django не создает документы с DTD, поэтому это не должно вызывать каких-либо проблем с типичным циклом от dumpdata до loaddata , но если вы скармливаете свои собственные XML-документы команде loaddata управления, вам нужно будет убедиться, что они не содержат DTD.

Исчерпание памяти формсета

Предыдущие версии Django не проверяли и не ограничивали данные подсчета форм, предоставляемые клиентом в форме управления набором форм, что позволяло исчерпать доступную память сервера, заставляя его создавать очень большое количество форм.

В Django 1.4.4 все наборы форм имеют строго установленное максимальное количество форм (по умолчанию 1000, хотя его можно увеличить с помощью max_num аргумента фабрики набора форм).

Утечка информации просмотра истории админки

В предыдущих версиях Django пользователь-администратор без разрешения на изменение модели мог по-прежнему просматривать представление экземпляров в Юникоде через журнал истории администрирования. Django 1.4.4 теперь ограничивает просмотр журнала истории администратора для объекта пользователями с разрешением на изменение этой модели.

Прочие исправления и изменения

  • Предотвращена утечка состояния транзакции из одного запроса в другой (# 19707).
  • Изменен синтаксис команды SQL для совместимости с MySQL 4 (# 19702).
  • Добавлена ​​обратная совместимость со старыми несолеными паролями MD5 (# 18144).
  • Многочисленные улучшения и исправления документации.

Copyright ©2020 All rights reserved