Исключение CSRF для запросов AJAX¶

Django включает механизм защиты CSRF, который использует токен, вставляемый в исходящие формы. Затем промежуточное программное обеспечение проверяет наличие токена при отправке формы и проверяет его.

До Django 1.2.5 наша защита CSRF делала исключение для запросов AJAX по следующим причинам:

• Многие наборы инструментов AJAX добавляют заголовок X-Requested-With при использовании XMLHttpRequest.

• Браузеры имеют строгие политики одинакового происхождения в отношении XMLHttpRequest.

• В контексте браузера единственный способ добавить пользовательский заголовок такого типа — это использовать XMLHttpRequest.

Поэтому для простоты использования мы не применяли проверки CSRF к запросам, которые на основе заголовка X-Requested-With выглядели как AJAX. Веб-фреймворк Ruby on Rails имел аналогичное исключение.

Недавно инженеры Google сообщили членам команды разработчиков Ruby on Rails о сочетании плагинов браузера и перенаправлений, которые могут позволить злоумышленнику предоставлять собственные HTTP-заголовки при запросе к любому веб-сайту. Это может привести к тому, что поддельный запрос будет выглядеть как запрос AJAX, тем самым нарушая защиту CSRF, которая доверяет запросам AJAX того же происхождения.

Майкл Козиарски из команды Rails обратил на это наше внимание, и мы смогли предоставить доказательство концепции, демонстрирующее ту же уязвимость в обработке CSRF в Django.

Чтобы исправить это, Django теперь будет применять полную проверку CSRF ко всем запросам, независимо от очевидного происхождения AJAX. Технически это обратно несовместимо, но было сочтено, что в этом случае риски безопасности перевешивают проблемы совместимости.

Кроме того, Django теперь будет принимать токен CSRF в пользовательском HTTP-заголовке X-CSRFTOKEN, а также в самой отправке формы, для удобства использования с популярными инструментами JavaScript, которые позволяют вставлять пользовательские заголовки во все запросы AJAX.

См. документацию CSRF, например, код jQuery <csrf-ajax>, который демонстрирует этот метод. Убедитесь, что вы просматриваете документацию для вашей версии Django, поскольку точный необходимый код отличается для некоторых старых версий Django.

FileField больше не удаляет файлы¶

В более ранних версиях Django, когда экземпляр модели, содержащий FileField, был удален, FileField взял на себя задачу также удалить файл из внутреннего хранилища. Это открыло путь к нескольким потенциально серьезным сценариям потери данных, включая откат транзакций и полей в разных моделях, ссылающихся на один и тот же файл. В Django 1.2.5 FileField никогда не удаляет файлы из внутреннего хранилища. Если вам нужна очистка потерянных файлов, вам придется сделать это самостоятельно (например, с помощью специальной команды управления, которую можно запускать вручную или запланировать периодический запуск, например, через cron).

Использование собственного SQL для загрузки исходных данных в тестах¶

Django предоставляет специальные перехватчики SQL для внедрения созданного вручную SQL в процесс синхронизации базы данных. Одним из возможных вариантов использования этого пользовательского SQL является вставка данных в вашу базу данных. Если ваш собственный SQL содержит инструкции INSERT, эти вставки будут выполняться каждый раз при синхронизации вашей базы данных. Сюда входит синхронизация любых тестовых баз данных, созданных при запуске набора тестов.

Однако в процессе тестирования Django 1.3 было обнаружено, что эта функция никогда не работала полностью так, как рекламируется. При использовании серверных частей базы данных, которые не поддерживают транзакции, или при использовании TransactionTestCase данные, вставленные с помощью пользовательского SQL, не будут видны в процессе тестирования.

К сожалению, не было возможности исправить эту проблему без введения обратной несовместимости. Вместо того, чтобы оставлять исходные данные, вставленные SQL, в неопределенном состоянии, Django теперь применяет политику, согласно которой данные, вставленные пользовательским SQL, не будут видны во время тестирования.

Это изменение влияет только на процесс тестирования. Вы по-прежнему можете использовать собственный SQL для загрузки данных в рабочую базу данных в рамках процесса syncdb. Если вам необходимо, чтобы данные существовали во время условий тестирования, вам следует либо вставить их с помощью test fixtures, либо использовать метод setUp() вашего тестового примера.

Подпись ModelAdmin.lookup_allowed изменена.¶

Django 1.2.4 introduced a method lookup_allowed on ModelAdmin, to cope with a security issue (changeset [15033]). Although this method was never documented, it seems some people have overridden lookup_allowed, especially to cope with regressions introduced by that changeset. While the method is still undocumented and not marked as stable, it may be helpful to know that the signature of this function has changed.