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

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

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

К сожалению, это означает, что среда 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.