Опасный заголовок Host¶

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

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

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

Валидация хоста отключена, когда DEBUG установлен в True, а также при запуске тестов.

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

XML-парсер в стандартной поставке Python уязвимы для ряда атак через внешние сущности и расширения. Django же использует его для десериализации фикстур БД. В принципе, в них не должно быть плохих данных, но мы решили перестраховаться и сделали невозможным атаки через это направление.

Эти вопросы проходят под номерами CVE-2013-1664 и CVE-2013-1665 стандартной библиотеки. Подробнее можно посмотреть на from the Python security team.

Сериализатор 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).

• Добавлена поддержка обратной совместимости со старыми «несолёными» паролями (#18144).

• Многочисленные улучшения и исправления документации.