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

21 апреля 2014 г.

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

Неожиданное выполнение кода с использованием 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 знают свои собственные типы, и большинство таких классов выполняют явное преобразование аргументов запроса в правильный тип уровня базы данных перед запросом. Однако три класса полей модели неправильно преобразовали свои аргументы:

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

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

Copyright ©2020 All rights reserved