Подмена заголовка 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-атаки через пользовательское перенаправление¶

В некоторых случаях 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 теперь дедуплицирует отправленные значения для решения этой проблемы.