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

13 января 2015

Django 1.4.18 исправляет несколько проблем безопасности в 1.4.17, а также регрессию на Python 2.5 в релизе 1.4.17.

Подмена заголовков WSGI с помощью смешения подчеркивания и тире

Когда HTTP-заголовки помещаются в окружение WSGI, они нормализуются путем преобразования в верхний регистр, преобразования всех тире в знаки подчеркивания и добавления символа HTTP_. Например, заголовок X-Auth-User станет HTTP_X_AUTH_USER в окружении WSGI (а значит и в словаре Django request.META).

К сожалению, это означает, что среда WSGI не может различать заголовки, содержащие тире, и заголовки, содержащие символы подчеркивания: X-Auth-User и X-Auth_User становятся HTTP_X_AUTH_USER. Это означает, что если заголовок используется чувствительным к безопасности способом (например, передавая информацию аутентификации от внешнего прокси), даже если прокси тщательно удаляет любое входящее значение для X-Auth-User, злоумышленник может быть в состоянии предоставить заголовок X-Auth_User (с подчеркиванием) и обойти эту защиту.

Чтобы предотвратить такие атаки, Nginx и Apache 2.4+ по умолчанию удаляют все заголовки, содержащие символы подчеркивания, из входящих запросов. Встроенный сервер разработки Django теперь делает то же самое. Сервер разработки Django не рекомендуется для использования на производстве, но соответствие поведению обычных производственных серверов уменьшает площадь для изменения поведения при развертывании.

Устранена возможная XSS-атака через URL-адреса перенаправления, заданные пользователем

Django полагается на ввод пользователя в некоторых случаях (например, django.contrib.auth.views.login() и i18n), чтобы перенаправить пользователя на URL «при успехе». Проверки безопасности для этих перенаправлений (а именно django.utils.http.is_safe_url()) не удаляли ведущие пробелы в проверяемом URL и поэтому считали URL типа \njavascript:... безопасными. Если разработчик полагался на is_safe_url() для обеспечения безопасных целей перенаправления и помещал такой URL в ссылку, он мог пострадать от XSS-атаки. В настоящее время эта ошибка не влияет на Django, поскольку мы помещаем этот URL только в заголовок ответа Location, и браузеры, похоже, игнорируют JavaScript там.

Атака на отказ в обслуживании против django.views.static.serve

В старых версиях Django представление django.views.static.serve() читало файлы, которые оно обслуживало, по одной строке за раз. Поэтому большой файл без новых строк занимал память, равную размеру этого файла. Злоумышленник мог воспользоваться этим и провести атаку типа «отказ в обслуживании», одновременно запросив много больших файлов. Теперь это представление читает файл по частям, чтобы предотвратить использование большого объема памяти.

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

Исправления

  • Чтобы сохранить совместимость с Python 2.5, шестая версия Django, django.utils.six, была понижена до 1.8.0, которая является последней версией, поддерживающей Python 2.5.
Вернуться на верх