Примечания к выпуску Django 1.8.16¶
1 ноября 2016
Django 1.8.16 исправляет две проблемы безопасности в 1.8.15.
Пользователь с жестко заданным паролем, созданный при выполнении тестов на Oracle¶
При запуске тестов с базой данных Oracle, Django создает временного пользователя базы данных. В старых версиях, если пароль не указан вручную в словаре настроек базы данных TEST, используется жестко закодированный пароль. Это может позволить злоумышленнику с сетевым доступом подключиться к серверу базы данных.
Этот пользователь обычно отбрасывается после завершения набора тестов, но не при использовании опции manage.py test --keepdb или если пользователь имеет активную сессию (например, соединение злоумышленника).
Теперь для каждого тестового запуска используется случайно сгенерированный пароль.
Уязвимость перепривязки DNS при DEBUG=True¶
Старые версии Django не проверяют заголовок Host на соответствие settings.ALLOWED_HOSTS при settings.DEBUG=True. Это делает их уязвимыми для DNS rebinding attack.
Хотя Django не поставляет модуль, позволяющий удаленное выполнение кода, это, по крайней мере, вектор межсайтового скриптинга, который может быть довольно серьезным, если разработчики загружают копию производственной базы данных в разработке или подключаются к некоторым производственным сервисам, для которых нет экземпляра разработки, например. Если в проекте используется пакет типа django-debug-toolbar, то злоумышленник может выполнить произвольный SQL, что может быть особенно плохо, если разработчики подключаются к базе данных с учетной записью суперпользователя.
settings.ALLOWED_HOSTS теперь проверяется независимо от DEBUG. Для удобства, если ALLOWED_HOSTS пуст и DEBUG=True, то разрешены следующие вариации localhost ['localhost', '127.0.0.1', '::1']. Если в вашем локальном файле настроек есть ваше производственное значение ALLOWED_HOSTS, то теперь вы должны опустить его, чтобы получить эти резервные значения.