Примечания к выпуску Django 1.6.10 ¶
13 января 2015 г.
Django 1.6.10 исправляет несколько проблем безопасности в 1.6.9.
Подмена заголовка 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()
представление считывало файлы, которые оно обслуживало, по одной строке за раз. Следовательно, большой файл без символов новой строки приведет к использованию памяти, равной размеру этого файла. Злоумышленник может воспользоваться этим и запустить атаку отказа в обслуживании, одновременно запросив множество больших файлов. Это представление теперь читает файл по частям, чтобы предотвратить использование большого количества памяти.
Обратите внимание, однако, что это представление всегда содержало предупреждение о том, что оно не усилено для производственного использования и должно использоваться только как средство разработки. Возможно, сейчас самое подходящее время для аудита вашего проекта и обслуживания файлов в производственной среде с использованием реального интерфейсного веб-сервера, если вы этого не делаете.
Отказ в обслуживании базы данных с ModelMultipleChoiceField
¶
Учитывая форму, которая использует ModelMultipleChoiceField
и
show_hidden_initial=True
(не документированный API), пользователь мог вызвать необоснованное количество SQL-запросов, отправив повторяющиеся значения для данных поля. Логика проверки ModelMultipleChoiceField
теперь дедуплицирует отправленные значения для решения этой проблемы.