Примечания к выпуску 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.