Примечания к выпуску Django 1.9.11¶
1 ноября 2016 г.
В Django 1.9.11 исправлены две проблемы безопасности в версии 1.9.10.
Пользователь с жестко запрограммированным паролем, созданным при выполнении тестов в Oracle.¶
При запуске тестов с базой данных Oracle Django создает временного пользователя базы данных. В старых версиях, если пароль не указан вручную в словаре настроек базы данных TEST, используется жестко закодированный пароль. Это может позволить злоумышленнику, имеющему сетевой доступ к серверу базы данных, подключиться.
Этот пользователь обычно удаляется после завершения набора тестов, но не при использовании опции manage.py test --keepdb или если у пользователя есть активный сеанс (например, соединение злоумышленника).
Для каждого запуска теста теперь используется случайно сгенерированный пароль.
Уязвимость перепривязки DNS при DEBUG=True¶
Старые версии Django не проверяют заголовок Host на соответствие settings.ALLOWED_HOSTS, когда settings.DEBUG=True. Это делает их уязвимыми для атаки с перепривязкой DNS <https://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
Хотя Django не поставляет модуль, позволяющий удаленное выполнение кода, это, по крайней мере, вектор межсайтового сценария, что может быть весьма серьезным, если разработчики загружают копию рабочей базы данных в разработке или подключаются к некоторым производственным службам, для которых, например, нет экземпляра разработки. Если в проекте используется такой пакет, как django-debug-toolbar, то злоумышленник может выполнить произвольный SQL, что может быть особенно плохо, если разработчики подключаются к базе данных с учетной записью суперпользователя.
settings.ALLOWED_HOSTS теперь проверяется независимо от DEBUG. Для удобства, если ALLOWED_HOSTS пуст и DEBUG=True, разрешены следующие варианты localhost ['localhost', '127.0.0.1', '::1']. Если в вашем локальном файле настроек указано производственное значение ALLOWED_HOSTS, теперь вы должны опустить его, чтобы получить эти резервные значения.