Неожиданное выполнение кода с использованием reverse()¶

Обработка URL-адресов в Django основана на сопоставлении шаблонов регулярных выражений (представляющих URL-адреса) с вызываемыми представлениями, а собственная обработка Django состоит из сопоставления запрошенного URL-адреса с этими шаблонами для определения подходящего представления для вызова.

Django также предоставляет удобную функцию reverse(), которая выполняет этот процесс в противоположном направлении. Функция reverse() принимает информацию о представлении и возвращает URL-адрес, который будет вызывать это представление. Разработчикам приложений рекомендуется использовать функцию reverse(), поскольку выходные данные функции reverse() всегда основаны на текущих шаблонах URL-адресов, а это означает, что разработчикам не нужно менять другой код при внесении изменений в URL-адреса.

Одна из сигнатур аргумента для reverse() — это передача пути Python, обозначенного точками, к желаемому представлению. В этой ситуации Django импортирует модуль, указанный этим пунктирным путем, как часть создания результирующего URL-адреса. Если у такого модуля есть побочные эффекты во время импорта, эти побочные эффекты возникнут.

Таким образом, злоумышленник может вызвать неожиданное выполнение кода при следующих условиях:

1. Присутствует одно или несколько представлений, которые создают URL-адрес на основе пользовательского ввода (обычно это параметр «следующий» в строке запроса, указывающий, куда перенаправить после успешного завершения действия).

2. Злоумышленнику известно, что на пути импорта Python на сервере существуют один или несколько модулей, которые выполняют выполнение кода с побочными эффектами при импорте.

Чтобы исправить это, reverse() теперь будет принимать и импортировать только пунктирные пути на основе модулей, содержащих представление, перечисленных в Конфигурации шаблона URL-адреса проекта, чтобы гарантировать, что только те модули, которые разработчик намеревался импортировать таким образом, могут или будут импортированы.

Кэширование анонимных страниц может раскрыть токен CSRF¶

Django включает в себя как инфраструктуру кэширования, так и систему предотвращения атак с подделкой межсайтовых запросов (CSRF). Система CSRF-защиты основана на случайном одноразовом номере, отправляемом клиенту в файле cookie, который должен отправляться клиентом при будущих запросах, а в формах — скрытом значении, которое должно быть отправлено обратно вместе с формой.

Платформа кэширования включает возможность кэширования ответов анонимным (т. е. не прошедшим проверку подлинности) клиентам.

Когда первый анонимный запрос к данной странице исходит от клиента, у которого нет файла cookie CSRF, структура кэширования также будет кэшировать файл cookie CSRF и передавать тот же одноразовый номер другим анонимным клиентам, у которых нет файла cookie CSRF. Это может позволить злоумышленнику получить действительное значение файла cookie CSRF и выполнить атаки, обходящие проверку файла cookie.

Чтобы исправить это, платформа кэширования больше не будет кэшировать такие ответы. Эвристика для этого будет:

1. Если входящий запрос не отправил файлы cookie и

2. Если ответ действительно отправил один или несколько файлов cookie, и

3. Если в ответе установлен заголовок «Vary: Cookie», то ответ не будет кэшироваться.

Приведение типов MySQL¶

Известно, что база данных MySQL выполняет «приведение типов» для определенных запросов; например, при запросе к таблице, содержащей строковые значения, но с использованием запроса, фильтрующего на основе целочисленного значения, MySQL сначала автоматически преобразует строки к целым числам и возвращает результат на основе этого.

Если запрос выполняется без предварительного преобразования значений в соответствующий тип, это может привести к неожиданным результатам, подобным тому, что произошло бы, если бы был изменен сам запрос.

Классы полей модели Django знают свои собственные типы, и большинство таких классов перед выполнением запроса выполняют явное преобразование аргументов запроса в правильный тип уровня базы данных. Однако три класса полей модели неправильно преобразовали свои аргументы:

• FilePathField

• GenericIPAddressField

• IPAddressField

Эти три поля были обновлены для преобразования их аргументов в правильные типы перед выполнением запроса.

Кроме того, разработчики полей настраиваемых моделей теперь предупреждаются в документации о том, что их классы настраиваемых полей будут выполнять соответствующие преобразования типов, а пользователям методов запроса raw() и extra(), которые позволяют разработчику предоставлять необработанный SQL или фрагменты SQL, будет рекомендовано убедиться, что они выполняют соответствующие преобразования типов вручную. перед выполнением запросов.

Исправления¶

• Исправлен ModelBackend, вызывающий UnboundLocalError, если get_user_model() вызывал ошибку (#21439).

Кроме того, шестая версия Django, django.utils.six, была обновлена ​​до последней версии (1.6.1).