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

Подмена заголовков 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.